Snap Sync: DepositNonce Data Correction

[axelKingsley]

What

Enables snap sync with untrusted parties by supplying a data source for DepositNonces.

Prior to Canyon Hard Fork, Deposit Nonces were not cryptographically verified. This PR supplies the Deposit Nonce data for most Superchain Registered Chains for the affected time period, and implements a correction function.

Why

We want Snap Sync to work without concern about trusting your peers. Today, a user could supply blocks with incorrect Deposit Nonces, and Snap Sync would not have a way of verifying. With this PR, nodes will be able to repair blocks with incorrect data, closing the attack vector.

How

• Deposit Nonces for the applicable time ranges (Bedrock or Regolith to Canyon) were collected via a new Receipt Reference Tool in the Optimism Monorepo.
• Each resulting dataset was saved as a gob, go binary format for data compression
• All gobs are located in a data directory, which is compiled into the binary using //go:embed directive
• Receipts which are going to be committed from snap sync are evaluated against the data, which is keyed by ChainID, and then by BlockNumber. The values in the data structure are only the Deposit Nonces for User Deposits in the block, in the order they appear.

If at any point the deposit nonces are not as expected, warnings are emitted to logs. More detailed activity is emitted to Trace Logs.

Testing

A unit test set is included to demonstrate that Nonces are Corrected when they are wrong.

I also Snap Synced Goerli with this code (a version with louder logs), and observed that over the range of blocks, Deposit Nonces were all checked.

Extending

This PR includes the required data for [OP, Base, Lyra, Mode, Orderly, Zora] Mainnet, as well as OP Goerli. To extend this correction to more chains, all that is required is that a new gob be checked into the data directory.

The file format created by the receipt reference tool should be used, as each gob is prefixed by its chainID, which is used to only load required files, keeping memory low.

[protolambda]

Changes look generally good, but one request: can this diff be documented in fork.yaml? Adding a category for "historical data" or something would be helpful. It will then automatically render it on https://op-geth.optimism.io/
Also, please squash the commits, since we don't have auto-squashing enabled in the op-geth repository. (since upstream commits need to be preserved).