Tx CLI proto module interface

[aaronc]

Summary

ref: #5864

This adapts the GetTxCmd method on AppModuleBasic to support the new tx cmd's we created in #5864 , simplifies those cmd's, and makes them amino compatible (with passing integration tests).

Details

• AppModuleBasic.GetTxCmd now takes a single CLIContext parameter
• renamed ClientTx -> TxBuilder and moved it as well as associated interfaces (like AccountRetriever) to client/context
• added NodeQuerier parameters to AccountRetriever methods
• adds TxGenerator and AccountRetriever fields to CLIContext
• renamed CLIContext.Marshaler -> CLIContext.JSONMarshaler
• adds InitWithInputAndFrom, etc. methods to CLIContext
• updated all module tx CLI & REST cmd's created in Transaction Client (CLI & REST) Protobuf Migration #5864, wired up in the modules and deleted deprecated code
• updated ADR 020 to reflect the changes

---

For contributor use:

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer

---

For admin use:

• Added appropriate labels to PR (ex. WIP, R4R, docs, etc)
• Reviewers assigned
• Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

[codecov]

Codecov Report

Merging #5989 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #5989   +/-   ##
=======================================
  Coverage   55.66%   55.66%           
=======================================
  Files         447      447           
  Lines       26866    26866           
=======================================
  Hits        14956    14956           
  Misses      10843    10843           
  Partials     1067     1067           

[lgtm-com]

This pull request introduces 1 alert when merging d0cd45a into 6469447 - view on LGTM.com

new alerts:

• 1 for Useless assignment to local variable

[aaronc]

@alexanderbez I started working on #5864 (comment) here. If you're able to take a quick look let me know if this approach works.

I realize that almost every new CLI method is touched by the refactoring already. Wondering if I should just go ahead and refactor those methods like I did for x/bank in the same PR or leave that for another PR?

[alexanderbez]

@aaronc there are a lot of moving pieces going on at this point. I'm having trouble keeping track. Are you referring to the use of any? Shouldn't we wrap up migrating modules first?

[aaronc]

@aaronc there are a lot of moving pieces going on at this point. I'm having trouble keeping track. Are you referring to the use of any? Shouldn't we wrap up migrating modules first?

@alexanderbez this is related to module tx CLI not Any, but since I'm waiting for feedback on various pieces there I was looking for something else that looked low hanging. But we can wait on this until later if it's easier to keep track.

[alexanderbez]

If we move to any, which it seems like we are (I presumed we had consensus). Wouldn't that render a lot of the CLI design discussion no longer that useful? It doesn't make sense to use all of these interfaces and generators when we can just go back to a StdTx, right? Or do you still plan on keeping the current design?

[aaronc]

If we move to any, which it seems like we are (I presumed we had consensus). Wouldn't that render a lot of the CLI design discussion no longer that useful? It doesn't make sense to use all of these interfaces and generators when we can just go back to a StdTx, right? Or do you still plan on keeping the current design?

So far I'm thinking it makes sense to keep the current design because at a very minimum it lets us safely support proto and amino transactions from the same code base. Which, I think for now is a requirement.

One thing I am noticing, is that with this design (both the tx and module design), we should probably be passing using the pointer version of CLIContext everywhere.

The only existing instance of AccountRetriever needs a CLIContext that has the node connection details setup. But if we construct the CLIContext and AccountRetriever before the tx command, the node connection details won't be populated in AccountRetriever and it will just fail. Passing around *CLIContext and just letting it be mutated would solve that.

In general I appreciate using the functional approach and not mutating things, but doesn't seem like accomplishes much in this case. There are other cases I've seen where maybe *CLIContext would be simpler.

What do you think?

[aaronc]

The alternative to *CLIContext everywhere would be making CLIContext or NodeQuerier a parameter of the AccountRetriever methods.

[alexanderbez]

We cannot pass a reference to a CLIContext -- so I'd opt for arguments in this case as you've suggested.

[fedekunze]

utACK

[alexanderbez]

utACK