feat(rollup): sync finalized batches from L1

[colinlyguo]

1. Purpose or design rationale of this PR

This PR adds a service to ensure the integrity and consistency of L2 data with the L1 data. When starting the node, it is initiated as a background process, guaranteeing the start procedure does not be blocked by rollupSyncService.

Ref link (see the last requirement of stage0): https://l2beat.com/scaling/projects/arbitrum#stage

Usage: --rollup.verify to enable.

L1 state: Syncing with ScrollChain Contract

1. Event types: CommitBatch, RevertBatch, and FinalizeBatch.
2. Calldata of CommitBatch event: get batch -> chunk range -> block ranges for each chunk.
3. Event topics: get BatchIndex, BatchHash, StateRoot, WithdrawRoot.

L2 state: Reconstruct Batch Header to get Batch Hash

1. Blocks: get from node state.
2. Block/chunk range of the batch: get from commitBatch calldata.
3. Parent batch hash and total l1 message popped before: store in db (after passing validation check).

Consistency check

1. Compare locally StateRoot, and WithdrawRoot with L1's.
2. Compare locally computed Batch Hash with L1's.
3. Close the node and shutdown once inconsistent.

DB:

1. Graceful Restart: Upon restarting, the sync service resumes from the last synchronized block height, preventing redundancy by syncing processed blocks.
2. Batch Meta Information: To construct the batch header, the database stores the hash of successfully reconciled batches along with the total count of L1 messages that have been processed.
3. Batch Chunk Ranges: For the construction of the batch header, the database saves the chunk ranges associated with each batch.

Unit tests:

1. accessors_rollup_event.go: read/write, read non-existing value, over-write.
2. rollup_sync_service.go: get/decode chunk ranges from calldata, new/start/stop (without rollup event data), validate batch.
3. l1client.go: test with mockEthClient (without rollup event data).
4. abi.go, block.go, chunk.go, batch_header.go: tested in scroll repo, consider moving them to a common repo.

2. PR title

Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:

• feat: A new feature

3. Deployment tag versioning

Has the version in params/version.go been updated?

• This PR doesn't involve a new deployment, git tag, docker image tag, and it doesn't affect traces
• Yes

4. Breaking change label

Does this PR have the breaking-change label?

• This PR is not a breaking change
• Yes

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1205434117001372

[colinlyguo]

sync looks good in Mainnet so far:
INFO [10-26|16:16:37.527] finalized batch progress batch index=900 finalized l2 block height=109,683

RevertBatch needs to be tested in Sepolia (has been tested previously), and will run later.

updated: also tested.