tests: 🧨 mock consensus exercises staking component

[cratelyn]

in #3588, we are building testing facilities for our App. we should write tests using the mock consensus engine that exercise the staking component.

we should write a test (or collection thereof) that performs the following:

1. start with a single validator, using the auto_app_state flow
2. run the chain for 1000 blocks
3. make a tx that defines a new validator, register its consensus signing key with the engine
4. after executing (3), check that:

• 4a. the validator appeared on chain in the defined state
  • "this is a negative test: we want to make sure that just because someone defined a validator, we don't actually do anything in the staking component's logic"
• 4b. the validator set did not change ("defined" validators don't affect staking logic)

5. make a tx that delegates more than the minimum amount (where is this defined?) to the new validator
6. after executing (5), check that:

• 6a. no changes to the validator set occur immediately
  • "this is another negative test, we want to be checking that (un)delegations are queued for the epoch transition rather than being effected immediately"

7. run to the end of the epoch (can hardcode or check epoch length), then check

• 7a. the validator becomes Active (it will probably skip Inactive because only one other validator)
• 7b. the two validators have different exchange rates
  • "this is also a negative test, we want to make sure that the validator exchange rate mechanism is actually doing stuff, we expect that the two validators would have different rates because the second validator is created later and the chain has already "warmed up" and run through a few epochs"

8. run 1000 blocks into the future, then check

• 8a. the new validator's uptime is being tracked correctly
  • "check that the mock engine is actually feeding correct-enough information to the application. the validator uptime is recorded by the app based on what validators were recorded as signing the block. i would expect there would be failures here when we first write this, and that resolving them would require co-development of the mock engine and the test. this will be a site of requirements discovery"

9. make a tx that undelegates some of the delegation tokens
10. after executing (9), check that:

• 10a. the client gets unbonding tokens
• 10b. the validator's voting power does not change immediately

11. run to the end of the epoch, then check

• 11a. the validator's voting power has decreased
• "(10a/b,11a) are again checking that undelegations are only processed at epoch boundaries"

12. run forward for the length of the unbonding period
13. make a tx that claims the unbonding tokens
14. after executing (12), check that:

• 14a. the client gets staking tokens out

---

• #3588
• #3845

[cratelyn]

xref #4009

[cratelyn]

updated the description of this issue to represent a checklist, to better track incremental steps towards completion. with #4001 merged, we are now progressing to the exciting stages of this work. :tada:

[cratelyn]

#4030 may conflict with work on 8a.

[cratelyn]

this work is now complete. there is certainly more coverage that we can continue to write in the future, but for now we have working examples of exercising the application's staking component. :tada: