Validate staking functionalities for sovereign -> consumer changeover

[shaspitz]

Slashing, jailing, etc. must work correctly after the upgrade and before the provider valset starts validating blocks. Confirm that consumer initiated slashing is functional even before CCV is established. We also need the "old" staking keeper around for at least the consumer unbonding period.

[shaspitz]

@mpoke here's an update after brainstorming and drafting up some code:

Concerns / notables

• How are delegation records migrated between staking keepers?
• Consider that staking token before changeover is STRD, and after it’s ATOM
• previously sovereign staking module (that satisfies democracy module?) needs to have slashing capabilities to slash STRD

Slash behavior

	After upgrade, before changeover complete	After changeover complete
val in old Valset only	call sovStaking.Slash() to slash STRD	call sovStaking.Slash() for STRD. Would need to add some tests around this confirming STRD can still be burned. Sov staking should handle unbonding
val in new Valset only	no-op	call ccvStaking.Slash() to send slash req
In both sets	call sovStaking.Slash()	do one of two above boxes depending on infraction height

Jail Behavior - TLDR always No-op

	After upgrade, before changeover complete	After changeover complete
Old Valset only	Call sovStaking.Jail(). essentially a no-op. new valset in effect by the time jailing happens	Validator already has zero power. No way to punish (no-op)
New Valset only	no-op	ccvStaking.Jail() (no-op)
In both sets	no-op	ccvStaking.Jail() (no-op)

Unjail Behavior

Always a no-op as well. Unjailing from the new valset is done on provider. Unjailing from old valset is n/a after the changeover is complete. Unjailing from old valset after upgrade, before changeover is complete doesn't really do much since the new valset takes over in 2-3 blocks anyways

The remaining methods from validators.go can be handled on a case by case basis, but I don't think we'd break anything if we just leave them unimplemented. Further testing can confirm this. Lmk if you have any thoughts

[mpoke]

Regarding the Slash behavior, I'm not sure we need the In both sets scenario. An infraction happens at an infractionHeight. If the "sovereign" valset was producing blocks at that height, then call sovStaking.Slash(). Otherwise, call ccvStaking.Slash() to send slash req.

Similarly for Jail Behavior.

Regarding the no-op of Jail Behavior, it may be useful to jail validators in the old valset as that will still affect their involvement in governance. However, this has very low priority. This opens the question of whether representatives can be jailed. @jtremback? If they can, this means that the Unjail must be directed to the gov-staking module.

[shaspitz]

On the topic of jailing a democracy power, I believe we could add an implementation to Jail in this file to achieve what you're talking about.

I will say it seems like an odd design to jail someone for some short amount of time from voting on gov proposals. Seems like it'd be fine and quite simple to just keep Jail() as fully a no-op

[shaspitz]

@mpoke a normal democracy consumer (not going through the changeover process) will treat Jail() as a no-op, I say we keep that functionality unless some consumer chain (esp Stride) desires other functionality

[shaspitz]

Confirm that consumer initiated slashing is functional even before CCV is established

@mpoke I believe this was a concern that was brought up during one of our conversations a couple weeks ago. To confirm the concern is already addressed by our code, I've added this test to the PR solving this issue