Sequencer: Derive L1 origin and attributes asynchronously

[BrianBland]

Is your feature request related to a problem? Please describe.
The sequencer synchronously determines the next L1 origin and its associated payload attributes as part of the block production process even though this is not particularly time sensitive with a large max sequencer drift tolerance. This means that blocking L1 RPC calls may significantly slow down or prevent block production in the worst case, while still consuming some of the sequencer's block time (typically 2 seconds) even in the best case.

Describe the solution you'd like
The L1 origin should be derived asynchronously and concurrently with respect to L2 block production, and this origin should only be selected if the payload attributes for this origin have also been derived.

Practically speaking, we can attempt to derive both of these pairs of L1Origin and PayloadAttributes in parallel each time the fork choice is updated, and then select the "best" origin when we start building the next block. We will need to select the next origin if and only if the max sequencer drift has been exceeded. In all other cases, it should be fine to fall back to the existing origin in order to avoid delaying block production.

Describe alternatives you've considered
We may wish to implement the L1Origin and PayloadAttributes generation as a single Deriver or even two Deriver's (AttributesWIthNextOrigin and AttributesWithCurrentOrigin), or perform these concurrent derivations as a subroutine within the sequencer.

Additional context
Add any other context or screenshots about the feature request here.

[tynes]

See #11100 for some existing work that may make this easier to implement

[BrianBland]

I already moved the typical L1Origin selection into an async process, but the next step after selecting the L1Origin is the payload attributes generation. The only implementation of this AttributesBuilder interface is the FetchingAttributesBuilder, which fetches the L1 block info and receipts inside of the call to PreparePayloadAttributes.

If we were to pass the L1 info into this method instead of having it fetch the data, then we could choose to only progress the L1Origin once we already have all of the data required to build attributes for this new origin. In other words, the L1OriginSelector may need to return L1Info and receipts instead of just an L1BlockRef, but then the AttributesBuilder would not need to make any network calls.

Another option would be to replace the L1OriginSelector with an AttributesWithOriginSelector which bundles together these two responsibilities, returning PayloadAttributes and an L1BlockRef for any new L2Head. This feels like an unnecessary degree of coupling, so my inclination is to go with the first option.

Is this the intended use of the event system, or should we be adding more intermediate events to coordinate the need for and availability of new L1 origin data?