staking: rework the unbonding delay mechanism

[erwanor]

Is your feature request related to a problem? Please describe.
Delegation pools follow an unbonding schedule determined by the chain to provide a window of opportunity for the consensus layer to propagate evidence of misbehavior (e.g., validator equivocation) back to the application so that it can be punished by the staking component ("byzantine slashing").

Currently, the unbonding schedule is defined in terms of epochs (StakingParameters::unbonding_epochs) that must elapse before an undelegation can be claimed or for a pool to become Unbonded.

However, since changes in the active validator set trigger epoch changes, it is possible for a consortium of active-set validators to expedite the unbonding period (in terms of the wall clock) by forcing early epoch changes.

Potential solution.

1. Make the unbonding schedule a number of blocks:
   • Penalty calculations work the same as before but we do an extra lookup to fetch the end block's epoch index
2. Add a minimum wall clock duration (X blocks must have elapsed AND Y hours)
3. Add a synchrony check to the chain to neutralize $f+1$ BFT time manipulation (penumbra: add a synchrony check to BFT time #3668)

** Other solutions you have considered **

1. Increase the unbonding_duration chain parameter
2. Rely completely on time-based duration (cons: a combination of logical and wall clock is more robust)

[hdevalence]

1. seems like the best avenue. The tokens are parameterized by an unbonding end epoch. so either we need to change the token semantics or add a new lookup from "original unbonding end epoch" => "not-before block height". it seems simlper to change the token semantics. if we did this in an upgrade we would be fine because the numbers would get bigger (any outstanding tokens would become unbondable post-upgrade, seems fine while we're on testnet).

we'll want to rely completely on block count to prevent time manipulation.

[erwanor]

The intuition behind "block height is harder to manipulate than BFT time" is that in one case, a $f+1$ cabal is enough (without a synchrony check) to accelerate the chain's wall clock because this is a large enough node quorum to censor honest proposers. Whereas the same attack would not work for accelerating block height (triggering new rounds incurs additional delay, self-defeating). Instead, in order to accelerate the clock, malicious proposers will have to set their precommit timeout to the lower bound of application execution, and the "acceleration factor" (vs. a 100% honest chain) is linear in their share of control of the network (because they will get selected for proposing with probability $f/N$).

(right?)

[aubrika]

Moved to backlog for PTO reasons