Snap Sync: consensus: handle legacy pre-bedrock header verification

[protolambda]

Description

Handle legacy pre-bedrock block-headers in consensus validation, to support snap-syncing without prior data-dir.

Very experimental. See optimism monorepo PR for context.

[trianglesphere]

PR is looking good. It needs a some lints to be fixed, but I'd like to get this in

[sebastianst]

We should run a test in our snap sync infra before merging.

[trianglesphere]

LGTM. I've also successfully used this code to snap sync op-goerli.

[protolambda]

Rebased on latest optimism branch, to resolve some conflicts with the receipts tests/code. (basefee->baseFee was renamed).

Fixed the unit-test, but had to jump through some hoops to make it work:

• historical blocks tests generates a chain
• config of above sets Bedrock at block 5
• chain import requires EVM processing
• EVM fails for < bedrock blocks, since we enforce don't support blocks to be processed pre-bedrock with EVM

Solution:

• generate with ethash faker as pre-bedrock consensus, like the upstream geth tests.
• swap the consensus of the node that we create (which by default creates a beacon consensus, wrapping an op-legacy consensus, for an optimism-configured chain-config)
• import the blocks
• swap back the consensus to op-legacy.

Related fixes:

• When loading receipts metadata, don't hydrate the L1-fee info with data if it's pre-bedrock. Don't just check if it's not a 1-tx block (as all pre-bedrock blocks are really on mainnet), since some tests have more txs than that.
• When checking if TTD has been reached, and if it's an optimism config, then enforce the bedrock block as the strict transition. Don't fall back on any TTD or ethash logic if it's not been reached yet, as there shouldn't be any other way to reach "merge" on an op-stack chain.

cc @trianglesphere, I think this unblocks this PR. PTAL