fix(builder): Resolve bugs on upstream flashblocks timing scheduler

[sieniven]

Summary

This PR fixes all the flashblocks timing intervals logic issue that was introduced from the upstream PR flashbots/op-rbuilder#380.

1. Biggest breaking change from the PR is that flashblock building was switched to start at the intervals calculated (first flashblock offset). This meant that the old logic of paylaod building triggered immediately on FCU is broken - reducing the throughput of the chain by a flashblock interval since the builder waits idle until the first send time (20% reduction in throughput with flashblock configuration of 200ms interval, 1s blocktime). This PR resolves this issue by reverting back to old behaviour, which is to start payload building immediately once FCU is received.

2. The flashblock offset configuration bug, which was only applied to the first and last flashblock. This PR resolves this issue by correctly applying the offset on every flashblock interval send time.

3. The new scheduler logic is problematic when calculating send times. This PR resolves them by:

   • reverting to the old logic of using a div_ceiling instead which aligns target_flashblock with the actual send_times vector calculated
   • Target flashblocks is calculated using original logic of remaining time / interval (remaining time = wall clock time when FCU arrives - payload timestamp) instead of the problematic configured block time / interval
   • Remove logic to append final deadline to the send vector which could result in 2 deadline timings inside send times vector if the scenario when FCU came delayed (but before payload timing)
   • Remove entire logic of truncating send time with target flashblocks

4. Breaking change on the payload builder refactor: extract flashblock timing code and test it flashbots/op-rbuilder#380. Because the additional check to safeguard that we are not building flashblocks past our target index, this could result in the an additional flashblock to start building and never be resolved or gossiped. For example, for 1s blocktime and 200ms interval, if FCU arrives at the start of block time, on the final 5th flashblock send time, we will stop building the last flashblock (index=5) and gossip that flashblock out. However without this guard, the payload builder actually starts building the 6th flashblock (index=6), which is problematic for X Layer builder (since we resolve payload on engine_getPayload). This PR restores the original behaviour and fixes this from happening.

5. Potentially breaking change on the new flashblocks scheduler, which changes the behaviour of the payload builder on the specific scenario that FCU arrives after exactly at or after payload timestamp. The old behaviour will use the configured block time / intervals to build that payload. However the new behaviour changes to building just 1 flashblock, which could potentially be backwards breaking. To safeguard this, the PR reverts to restore the old behaviour.

Test coverage

In addition, this PR extends the unit tests on the flashblock timing scheduler to add more comprehesive unit coverages, testing all possible scenarios to ensure flashblocks interval send times generated are correct:

• FCU arrives on time, full block time to payload timestamp
• FCU arrives late, less than full block time to payload timestamp
• FCU arrives very late, exactly at payload timestamp
• FCU arrives very late, past payload timestamp

[sieniven]

ERC20 stress test with 500M block gas limit for 20+ mins, max throughput of the chain is stabilized at 10+K TPS with no drop off in throughput.

[dloghin]

lgtm