[wip] Disseminate approvals and auxiliary info

[samliok]

wip: disseminates approvals and auxiliary info in a more efficient way regardless of validator status

This PR reworks how epoch-transition approvals are produced and propagated. Instead of a validator only contributing its approval when it happens to be the block builder, every prospective next-epoch validator AND non-validator now broadcasts its approval (and any required auxiliary info) as soon as it observes a finalized block indicating an epoch transition is underway.

A new EpochTransitionListener (transition_listener.go) listens to finalized blocks and reacts based on the block's type:

• Transitioning block indexed: an epoch change is incoming. If the referenced P-chain height's validator set includes our node ID:

  • If the auxiliary info history is not yet sufficient, we generate our auxiliary contribution and broadcast it as a new AuxiliaryInfo message.

  • If aux info is sufficient, we sign an approval over (nextPChainReferenceHeight, auxInfoDigest) and broadcast it as a new EpochTransitionApproval message, feeding it to our own approval store as well. A timeout task tracks the approval so it can be re-sent on network issues until the epoch change completes.

• Sealing block indexed: the transition is complete. Stale approval timeout tasks for the old epoch are cleared, and the onEpochChange callback fires with the new epoch's validator set.

Why this is better than the previous flow

• Faster epoch transitions. Previously a validator's approval was only created inline during block building, so the sealing quorum accumulated one builder at a time. Now approvals are processed and sent asynchronously from block building.

• One code path for validators and non-validators. Both roles react to indexed blocks through the same listener, meaning we dont need to re-write logic for non-validators.

• More simplex block building. The builder no longer generates approvals or aux info; it just aggregates whatever the ApprovalStore has collected when deciding whether the epoch can be sealed.

[yacovm]

If we rely on blocks being indexed to be the trigger for message dissemination, we need to add a test that ensures that if we only notarize blocks and do not finalize them for a few rounds, the MSM doesn't get stuck. I don't think it will get stuck because we should keep on building blocks when we're in the collecting approvals state, but we should nevertheless test this.

Now when we merged the orchestration layer we have the test infrastructure to test this with MSM and epoch both being production implementations in the test.