Validator Creation Updates

[alexanderbez]

Summary

Brain dump from conversations with @jaekwon @sunnya97 and @rigelrozanski with regards to allowing new (non-genesis) validators to be created while still allowing them to unjail and immediately unbond (under the assumption that "normal" transfers are disabled):

• Remove NewMsgCreateValidatorOnBehalfOf and any related logic
• Ensure that the operator address equals the delegator address in MsgCreateValidator#ValidateBasic
• Ensure the bond amount meets the self-delegation minimum MsgCreateValidator#ValidateBasic (already exists)
• Unit/integration tests

Needs further discussion:

• Ensure you cannot edit a validator if self-delegation is below minimum

Note: This assumes the validator can transfer some amount of uatoms to the new account in order to self-bond.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[jackzampolin]

Is this being implemented in #3787

[alexanderbez]

No this is separate :)

[cwgoes]

It doesn't seem problematic, but why prevent editing validators with below-minimum self-delegation?

[alexanderbez]

@cwgoes -- something @jaekwon recommended. I can't see any immediate good reason for doing so either.

[ice-cronus]

Hello @alexanderbez! May be you still remember, why equality of delegator and validator address is required by business logic? We're looking for some scenario that another account is responsible to pay self-delegation fee for validator address, any possible side effects if we are disable that check?