Refactor usages of bech32 ValAddress signers

[aaronc]

Problem Definition

While working on #11275, I discovered that some Msg's use ValAddress bech32 encoding rather than AccAddress bech32 for Msg signers, (i.e. cosmosvaloper12345abcef vs cosmos12345abcef), specifically:

• x/staking
  • MsgCreateValidator
  • MsgEditValidator
• x/slashing
  • MsgUnjail
• x/distribution
  • MsgWithdrawValidatorCommission

Proposal

I can think of a few approaches for dealing with this:

1. Refactor these Msg's to use AccAddress bech32
2. Support either ValAddress or AccAddress in address.Codec and decode both to address bytes
3. Add some special annotations to indicate which signers use ValAddress encoding. For instance we could write (cosmos_proto.scalar) = "cosmos.ValidatorAddressString" on these fields to indicate the encoding

I'm personally leaning towards approach 3 because it's the most explicit and isn't protocol breaking. I actually see many messages which use validator addresses annotated with cosmos.AddressString as their cosmos_proto.scalar encoding and this is just incorrect. At a minimum we should fix these annotations. If we do fix them, then it's a matter of refactoring our existing GetSigners code to handle these cases. This is annoying for sure, but better long term as we can also refactor this code to support bytes signers in the future as some people discussed in #13140.

[tac0turtle]

I would rather go with 1. Valper should be an internal accounting thing. Signers should all be the same format imo.

[aaronc]

What do you think about doing this in a way that will allow bytes addresses in the future?