Inconsistency of message types and json keys in modules

[kwunyeung]

@jackzampolin Here is a list of message types registered in the modules.

x/bank

1. cosmos-sdk/Send
2. cosmos-sdk/MultiSend

x/distributions

1. cosmos-sdk/MsgWithdrawDelegationReward
2. cosmos-sdk/MsgWithdrawValidatorCommission
3. cosmos-sdk/MsgModifyWithdrawAddress

x/gov

1. cosmos-sdk/MsgSubmitProposal
2. cosmos-sdk/MsgDeposit
3. cosmos-sdk/MsgVote

x/slashing

1. cosmos-sdk/MsgUnjail

x/staking

1. cosmos-sdk/MsgCreateValidator
2. cosmos-sdk/MsgEditValidator
3. cosmos-sdk/MsgDelegate
4. cosmos-sdk/Undelegate
5. cosmos-sdk/BeginRedelegate

x/ibc

1. cosmos-sdk/IBCTransferMsg
2. cosmos-sdk/IBCReceiveMsg

Some of them have "Msg" as prefix and some of them not while types in IBC have it as suffix. It looks like there is a convention that when you register concrete type, you put the type string the same as the struct but this is not the case as you have cdc.RegisterConcrete(MsgDelegate{}, "cosmos-sdk/MsgDelegate", nil) but cdc.RegisterConcrete(MsgUndelegate{}, "cosmos-sdk/Undelegate", nil). It will be easier to follow if you can keep a naming convention.

Another inconsistency is in the JSON keys. Some of them are using address and some of them are addr. This can be found in the x/staking module. The keys in create_validator are delegator_address and validator_address but in delegate they are delegator_addr and validator_addr.

This also make the tags a little bit hard to follow. When there are delegator_addr and validator_addr in the tx message, the tags would be delegator, source-validator, destination-validator, etc.

It will be great if these terms can be in consistence following a convention.

[alexanderbez]

Thanks @kwunyeung -- seems like we have some cleaning up to do in some of the modules.

[jackzampolin]

Thank you for the detailed bug report @kwunyeung!