client: reduce the amount of magic

[ebuchman]

Using cobra and viper makes for a lot of magic that can be hard to follow.

It would be nice if functions came with more clarity about what kind of global/external state they are accessing.

Only a very few/small number of functions should utilize global/external state and should be well documented to be doing so.

[rigelrozanski]

Having magic is important is some regard to help offload logic from the new application developers side. The whole paradigm of client is that is can wrap transaction/query commands to add viper, and then also take care of handling the logic associated with those flags that it has created - This is positive as much of this logic with come totally standard many transactions and should not need to be explicitly defined by a new application. Right now I've taken on a few additions to the existing client structure which was (I reckon) originally imported from SDK1 - I haven't really done any major wholistic refactors of client to date - totally agree one is necessary, although I'm not sure I'd like to limit the "magic" (I guess it depends on what you specifically mean). Broadly speaking I would proposed to reorganize the functionality to group:

• Flag wrapping and associated magical functions for Standard Tx
• Flag wrapping and associated magical functions for Query
• Key logic (maybe taking out any viper references??)
• Custom fully formed transactions (currently the tx folder)

^ probably missing some stuff this is just off the top of my head - thoughts? I can take this on this week

[ebuchman]

Yes I'm interested in explicitly clarifying where calls to global assets are happening. Just want the code to be easier to grok and reason about, which it currently is not with the global viper/cobra calls everywhere

[rigelrozanski]

Here is an idea - let's remove global viper calls all together - why we even need them?!

[rigelrozanski]

Note this is blocking on #544

[ebuchman]

This is the only kind of magic I want to keep around: https://www.youtube.com/watch?v=UqyT8IEBkvY

[ebuchman]

Tiny amount of work done towards this in #624

Still needs lots more

[ebuchman]

Replaced by #721