Fix off-by-one in process_pending_consolidations

[mkalinin]

Fixes an off-by-one in process_pending_consolidations, due to this bug a consolidation processing was delayed by an epoch which compounded with withdrawal sweep resulted in withdrawing the balance to EL instead of consolidating it to the target.

The fix

The expected logic of pending consolidation and deposit processing is as the following:

• Let the next_epoch be the epoch the state is being transitioned to
• Process pending consolidation if source.withdrawable_epoch == next_epoch to prevent consolidating balance from being withdrawn
• Process pending deposit if source.withdrawable_epoch == next_epoch + 1 to prevent the balance to be accrued to the consolidating validator (as consolidations are processed after deposits in the epoch processing)

The actual logic uses current_epoch instead of the next_epoch. Note that with process_pending_balance_deposits case this would result in just delaying the processing by an epoch, while with consolidations it would lead to much worse outcome. The corresponding spec tests are added to cover both scenarios.

Huge gratitude to @parithosh and entire devops team for finding this bug on devnet-2. Fantastic catch!! 🙌

[fradamt]

Lgtm! Your explanation perfectly matches the intended behavior, as far as I can tell from what I have previously noted in the wip annotated spec.

Nice catch 🐼s :)

[hwwhww]

LGTM! Thank you @mkalinin!

Some lines in tests seem a bit repeated, but I also didn't find a way to refactor the fragmented assertions better. 😭

Left a minor suggestion. I can refactor it tomorrow if you think it makes sense too.

[hwwhww]

edited: run_epoch_processing_with compute_state_by_epoch_processing_to

Another solution is to make run_epoch_processing_to return values:

def run_epoch_processing_to(spec, state, process_name: str):
    ...
    pre = state.copy()
    ...
    return pre, state

and call it with return values in tests:

    pre, post = yield from compute_state_by_epoch_processing_to(spec, state, "process_pending_consolidations")