Holocene-D: Pipeline improvements tracker

[sebastianst]

Tracking (non-blocking) observations and todos from #12506

• Garbage collect left-over state in state multiplexers?
• Refactor Reset to be called recursively on previous stages? So going from a horizontal model, where the pipeline iterates over the stages and Resets each, to a vertical model where each stage owns the previous and resets it. There's only a single Reset that actually makes a network call (L1Retrieval.Reset), while all other resets simply clear some fields and slices, so there's no real value in stepping through each reset individually. Note that this is actually more consistent to how each stage also fetches data from the previous stage (prev.NextData etc) - it is not fetched by the pipeline on each stage and then passed on to the next stage. I also choose to make FlushChannel work with this vertical ownership model as well. (And the Rust implementation of the DP also works with the same model.)
• Clarify if the DepositsOnlyPayloadAttributesRequest case in EngDeriver.onPayloadProcess can actually happen. To the best of my understanding the FCU call should already fail before during derivation.

See also #12444

[protolambda]

Can this be closed?

[sebastianst]

Moved the modular fork handling notes into its own issue #14756

[sebastianst]

In view of ethereum-optimism/design-docs#213 we can close this issue for now.

[ajsutton]

Reopening as we still have 4 todos in the code for this issue:

ethereum-optimism/optimism #12490        | Holocene-D: Pipeline improvements tracker                         | op-node/rollup/types_test.go:779                  
ethereum-optimism/optimism #12490        | Holocene-D: Pipeline improvements tracker                         | op-node/rollup/types.go:511                       
ethereum-optimism/optimism #12490        | Holocene-D: Pipeline improvements tracker                         | op-node/rollup/derive/batch_mux.go:35             
ethereum-optimism/optimism #12490        | Holocene-D: Pipeline improvements tracker                         | op-node/rollup/derive/channel_mux.go:39           

Seems like those todos could potentially just be removed.