Handle top-ups to exiting/exited validators

[fradamt]

This PR does the same thing as #3650, which was based on the EIP-7251 spec. Meanwhile, the rationale for it has evolved somewhat, with the realization that it is actually more security-critical than previously realized understood. An attacker can do the following:

1. Initiate a validator’s exit
2. Make a top-up while the validator is still exiting
3. The top-up happens before the exit
4. Once the validator exits, the topped-up balance leaves the validator set without going through the churn

This can lead to churn limit invariants being violated, even though top-ups go through the deposit churn. The reason for this is subtle: the top-ups can go through the deposit churn slowly, over a long period of time, but the same balance can then exit much faster. For example, say the exit queue is one week long, while the activation queue is completely empty, and an attacker executes the strategy above, exiting validators with minimum balance and topping them up to max balance. Because of the exit queue being full, the large top-ups have one whole week to go through the deposit churn and be processed. Moreover, all exits happen very fast once the week is over, because the validators had minimum balance when the exits were initiated, and so the exits are scheduled very close to each other. The end result is that a bunch of very large exits all happen in a short period of time.

More details in this section of the WIP annotated spec

[prestonvanloon]

Makes sense to me

[michaelsproul]

It seems this change is necessary for security, but I just wanted to note that it probably has a detrimental impact on the performance of Lighthouse's single-pass epoch processing.

Previously, process_pending_balance_deposits did not depend on state.validators, which allowed us to use the following algorithm:

1. Loop through pending_balance_deposits and collect applicable deposits into a hashmap
2. Loop (once) through state.validators and for each index apply all deposits (from the hashmap) for that index

Now we are forced to add random-access in step 1 to load validators and check their exit_epoch and withdrawable_epoch. This is probably acceptable because the length of pending_balance_deposits is not enormous, but I thought I'd just note the sorts of implementation challenges that spec changes like this present.

[mkalinin]

@michaelsproul thanks for raising this performance point, I am currently working on the set of changes to the eip6110 that was agreed during Nyota (#3689 (comment)).

Those changes leverage on and extend pending_balance_deposits to keep full deposits and do full deposit processing including sig verification and new validator creation, so it involves reads and modifications to the state.validators. One of the points that we have agreed is to limit a number of deposits that can be processed during one pass. Although, it is already limited by the churn.

[michaelsproul]

Thanks for the update @mkalinin, I had not been following!

A short queue of deposits that we can process with random access sounds fine