Add below-threshold validator set

[brentstone]

Based on v0.17.4.

Closes #1128.

This PR implements a third validator set in addition to the consensus and below-capacity sets: the below-threshold set. All validators with stake below the validator_stake_threshold parameter are placed into this set, which is unordered, unlike the other two validator sets. Smaller amounts of data are needed to be kept in storage for validators in this set.

[brentstone]

Several unit tests break because arb_genesis_validators generates genesis validators whose staked tokens are all below the validator_stake_threshold. Some hackier ways of solving this is to make the validator_stake_threshold 0 or 1 namnam or to just lower the threshold to some value where it is less likely to arbitrarily generate a set of validators all of whose stake is below this number.

The more rigorous solution is to modify arb_genesis_validators to take a PosParams as input. Then if the generated validators all have stake less than validator_stake_threshold, we can generate one additional genesis validator with random stake that is assured to be at least as large as this.

@tzemanovic

[tzemanovic]

I think we need to be careful with removing this check. We can do it, but we should probably enforce that the validator_stake_threshold and tm_votes_per_token * u64::from(validator_stake_threshold) are non-zero

[tzemanovic]

same with if prev_tm_voting_power == 0 ... for below capacity

[brentstone]

enforce with debug_asserts or by returning None values?

[brentstone]

maybe smth like

if params.validator_stake_threshold == token::Amount::default() && *prev_tm_voting_power == 0 && *new_tm_voting_power == 0
                {
                    tracing::info!(
                        "skipping validator update, {address} is in consensus \
                         set but without voting power"
                    );
                    return None;
                }

?

[brentstone]

ALSO, do we still need this Lazy type wrapped around prev_tm_voting_power and new_tm_voting_power?

[tzemanovic]

I think we could enforce in the paramaters PosParams::validate that validator_stake_threshold and tm_votes_per_token * u64::from(validator_stake_threshold) are non-zero - only thing is that we're currently not using this function but we should probably fix that anyway. We could use it for genesis parameters validation and for on-chain parameters change, which is only allowed via governance.

If we enforce these invariants on the params then we can remove the check in here as we couldn't have a validator with 0 TM voting to enter the consensus set. That being said, what you've done LGTM and I don't think we need to change this immediately.

I think we should keep Lazy as the first condition if matches!(prev_state, Some(ValidatorState::Consensus)) might short-circuit in which case we don't need to compute these.

[brentstone]

pls update wasm

[tzemanovic]

I'll squash the fixup commits and add this to draft

[brentstone]

Merged in v0.18.0.