staking(tests): add validator tombstoning scenarios

[erwanor]

This is perhaps best to split into multiple tickets, but at a high-level we want to:

• Enshrine in tests that Tombstoned is a terminal state
• Check that exchange rates and validator rewards are always penalized
• Check that new delegations are impossible
• Check that that undelegation claims are instantaneous
• Check that claims are always factoring in the penalty even if tombstoning happened after undelegating

For context, the application receives misbehavior evidence from comet in the BeginBlock packet (and starting in 0.38, FinalizeBlock either way we want to process evidence before tx execution), the application then forwards it to the staking component in ValidatorManager::process_evidence which then records the appropriate penalty and trigger a state transition.

/// Evidence of validator misbehavior.
///
/// [ABCI documentation](https://docs.tendermint.com/master/spec/abci/abci.html#evidence)
#[derive(Clone, PartialEq, Eq, Debug)]
pub struct Misbehavior {
    /// The kind of evidence.
    ///
    /// Note: this field is called `type` in the protobuf, but we call it `kind`
    /// to avoid the Rust keyword.
    pub kind: MisbehaviorKind,
    /// The offending validator.
    pub validator: Validator,
    /// The height when the offense occurred.
    pub height: block::Height,
    /// The corresponding time when the offense occurred.
    pub time: Time,
    /// Total voting power of the validator set at `height`.
    ///
    /// This is included in case the ABCI application does not store historical
    /// validators, cf.
    /// [#4581](https://github.com/tendermint/tendermint/issues/4581)
    pub total_voting_power: vote::Power,
}

Ostensibly, there is very little validation done by the application because we assume that CometBFT has done it for us. We can't however assume that the evidence gets only delivered once or make any assumptions that are downstream of validator behavior (since it is byzantine!).

This is good news, because this means that to test this part of the staking logic we just need to:

• have a method that creates a stub Misbehavior datum that specifies some cometbft address (that's the only data we need to populate!)
• have a hook that inject Misbehavior into a BeginBlock packet

And then we "just" need to inspect the staking state to assert the various invariants that we are looking for.

Originally posted by @erwanor in #4049 (comment)

[erwanor]

@cratelyn pointed out that the preferred pattern is to build mock data in the test and use an interface to inject it in block execution (unless I misunderstood)

[cratelyn]

🔗 some handy links

@erwanor, following up with some links to help you on your way!

penumbra/crates/test/mock-consensus/src/block.rs

Lines 58 to 61 in 70a3ed2

	/// Sets the evidence [`List`][evidence::List] for this block.
	pub fn with_evidence(self, evidence: evidence::List) -> Self {
	Self { evidence, ..self }
	}

the block builder has a with_evidence() method to set a block's list of malfeasance, in its entirety. we may want an add_evidence() method too, like the add_tx, which could append a new piece of evidence, without discarding any existing data.

the evidence field here should no longer be ignored. now, it should be passed along from the block constructed by Builder::finish() as a new parameter to the abci submodule's TestNode::begin_block() method, and used to fill byzantine_validators, here:

penumbra/crates/test/mock-consensus/src/abci.rs

Line 52 in 70a3ed2

byzantine_validators: Default::default(),

i suspect that most of what you'll need is already there! the one wrinkle will be sorting out the discrepancy between the tendermint::evidence::Evidence stored in a block's evidence: List, and the begin block request's byzantine_validators. it looks like there's a TryFrom<Evidence> we can use for that.