Restructure CLI tests

[rigelrozanski]

Couple things here. The use of "go-bash" is extremely finicky thus we haven't been adding new CLI tests to that framework - not to mention core code which is "go-bash" is kinda complex.

What we ought to be doing is testing the CLI by calling the cobra commands directly with expected input arguments but also only testing the cobra command - not the underlying handler functionality.

Conveniently we can do this already by just generating the message but not broadcasting it using the --generate-only flag.

blocks #2568

CC @cwgoes

[jackzampolin]

I think its also helpful to have end-to-end tests here, but regular unit tests should also be there. I'm pro-CLI unit tests.

[rigelrozanski]

Honestly - that was my opinion as well once-upon-a-time but since experiencing the immense horrors of bash - I think we can test the CLI in two chunks: one to make sure messages are sent, and one that tests the messages (the later is basically the simulation right now).

I doubt that end-to-end testing would find anything if we have adequate coverage for the above mentioned tests - however, in addition, full end-to-end testing can just be performed manually as we're already doing with testnets - we shouldn't expect this project to be maintaining any bash code.

[jackzampolin]

I did this. Closing.