Gloas Range Sync Modifications

[ethDreamer]

We are currently reworking block processing in the ePBS context (block and envelope processing).

When looking at the flow for range sync we see:

1. Fully available RPCBlocks come into process_chain_segment()
2. These are passed to process_blocks()
3. This goes to process_chain_segment() on the beacon chain
4. This calls process_block() in a loop for each block

This will need to be replaced in gloas. Instead of a Vec of fully available RPCBlocks, sync will need to collect and provide a Vec<ChainNode> to process_chain_segment() where:

pub enum ChainNode<E: EthSpec> {
    Envelope(Box<AvailableEnvelope<E>>),
    Block(Box<BeaconBlock<E>>),
}

and then these will need to be passed down the call stack until the beacon chain calls either process_block() or process_envelope() depending on what kind of ChainNode it is. I'm still working on writing process_envelope().

We are pursuing a philosophy of replacing old code with new functions that work only after gloas so we can eliminate old technical debt after the gloas fork is live. So the first step is to identify some of the functions that will need to be replaced and submitting a PR to unstable to rename them to make way for the new functions. For example, rename the existing process_chain_segment() to something like process_chain_segment_pre_gloas(). Which functions need to be renamed will need to be thought through.

[eserilev]

Based on conversations with Mark, we'll be looking at introducing a CompleteSlot (name TBD) struct

pub struct CompleteSlot<E: EthSpec> {
    block: Box<BeaconBlock<E>>,
    envelope: Option<Box<AvailableEnvelope<E>>>,
}

Which indicates the Block and AvailableEnvelope are coupled and fully available

I'm also looking at introducing a gloas variant of RangeBlockComponentsRequest that will handle the coupling of the blocks, payload envelopes and columns. This variant will most likely be it's own separate type with its own unique codepath to differentiate between gloas and pre gloas logic