Create Vesting Account Message

[alexanderbez]

Description

• Turn x/auth/vesting into a proper sub-module (implements AppModuleBasic and AppModule)
• Implement a new MsgCreateVestingAccount message and corresponding handler
• Add CLI handler to x/auth/vesting to create a MsgCreateVestingAccount tx (only delayed and continuous accounts can be made)
• Update SimApp

Note, we're still not allowing a custom start_time.

closes: #4287

/cc @zmanian @cwgoes

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• 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
• Review Codecov Report in the comment section below once CI passes

[codecov]

Codecov Report

Merging #7209 into master will decrease coverage by 0.01%.
The diff coverage is 51.61%.

@@            Coverage Diff             @@
##           master    #7209      +/-   ##
==========================================
- Coverage   55.16%   55.14%   -0.02%     
==========================================
  Files         580      584       +4     
  Lines       40359    40512     +153     
==========================================
+ Hits        22263    22341      +78     
- Misses      16233    16301      +68     
- Partials     1863     1870       +7     

[alexanderbez]

@cwgoes I need to undo commit d34ef20 that contains your recommendation, because we call SendCoins in multiple contexts (e.g. module to module), which is allowed when done internally (e.g. tokens going from unbonding to bonding).

Either we

1. Introduce a second new SendCoins that we call only from the message handler(s), OR
2. We just duplicate the checks (i.e. undo the commit).

Thoughts?

[cwgoes]

@cwgoes I need to undo commit d34ef20 that contains your recommendation, because we call SendCoins in multiple contexts (e.g. module to module), which is allowed when done internally (e.g. tokens going from unbonding to bonding).

Either we

1. Introduce a second new SendCoins that we call only from the message handler(s), OR
2. We just duplicate the checks (i.e. undo the commit).

Thoughts?

Ah, I see. Is the issue with the SendEnabledCoins check or the BlockedAddr check? It's the latter that seems (to me) like it should really be in SendCoins, although I didn't write the feature so I'm just guessing at the intent.

Duplicating the SendEnabledCoins check isn't too bad (although this API is not perfect, I think...)

[AdityaSripal]

I assume these had to do with vesting accounts? Is this logic moved elsewhere now or is it irrelevant?

[alexanderbez]

nothing to do with vesting.

[alexanderbez]

It was moved to x/bank SendCoins to keep code DRY

[alexanderbez]

Updated @cwgoes

[cwgoes]

utACK 🎉

[cwgoes]

Who else should review this, maybe @AdityaSripal @alessio?

[AdityaSripal]

LGTM!

[alexanderbez]

I'll give this another day or so before I merge.

Note, @cwgoes I had to revert the DRY changes you've suggested. It was causing issues with InitGenesis because we end up having transfers disabled for some seeds which causes x/staking InitGenesis to fail.

We should eventually refactor the way we send coins to make it more flexible (e.g. add a parameter to SendCoins, but I'm going to leave this for another PR.