core, eth/downloader: implement pruning mode sync

[rjl493456442]

This pull request introduces new sync logic for pruning mode.

Pruning Mode:

Geth now supports two chain history modes (-history.chain): all and postmerge.

• all (default): Retains the entire historical chain as usual.
• postmerge: Discards chain segments before the configured cutoff point and skips them during synchronization.

The cutoff point is defined as the first block after the Paris fork and will be dynamically
adjusted in the future.

---

Sync mechanism with chain cutoff

A consensus has been reached across different EL implementations that chain
segments before the merge point will be pruned by default in the near future.
This means these segments—specifically block bodies and receipts—will no longer
be available in the P2P network. As a result, these components must be skipped
during retrieval in pruning mode.

---

Internally, Geth uses a freezer to maintain historical chain segments, which must
be inserted sequentially. This raises the question of how to handle the gap between
the genesis block and the first block after the cutoff in the freezer.

Two options were considered:
(a) Introducing a new freezer API to set the freezer tail to an arbitrary block number.
(b) Replacing chain data before the cutoff with null data.

The latter option is simpler and functionally equivalent to the former. When retrieving
data for chain segments before the cutoff, null values will be returned, indicating that
these items do not exist locally. Additionally it's a more robust approach that all chain
segment inserted into the freezer always in an atomic manner. Lots of complexities are
needed in approach (a) if this property is required. For example, we must guarantee
the header x write and body table tail shifting to x happen atomically.

Therefore, the approach (b) is chosen for the sake of simplicity.

---

Additionally, this pull request introduces some important changes worth highlighting.

Originally, in snap sync, the header chain and other components (bodies and receipts)
were inserted separately. However, in Proof-of-Stake, this separation is unnecessary
since the sync target is already verified by the CL.

To simplify the process, this pull request modifies InsertReceiptChain to insert headers
along with block bodies and receipts together. Besides, InsertReceiptChain doesn't
have the notion of reorg, as the common ancestor is always be found before the sync
and extra side chain is truncated at the beginning if they fall in the ancient store.
The stale canonical chain flags will always be rewritten by the new chain. No explicit
reorg logic required in the InsertReceiptChain.

[rjl493456442]

Snap sync with --chain.history=postmerge

+-----------------------+---------------------------+------------+------------+
|       DATABASE        |         CATEGORY          |    SIZE    |   ITEMS    |
+-----------------------+---------------------------+------------+------------+
| Key-Value store       | Headers                   | 51.39 KiB  |         81 |
| Key-Value store       | Bodies                    | 6.05 MiB   |         81 |
| Key-Value store       | Receipt lists             | 6.33 MiB   |         81 |
| Key-Value store       | Difficulties (deprecated) | 0.00 B     |          0 |
| Key-Value store       | Block number->hash        | 3.32 KiB   |         81 |
| Key-Value store       | Block hash->number        | 863.83 MiB |   22092473 |
| Key-Value store       | Transaction index         | 13.39 GiB  |  388581603 |
| Key-Value store       | Bloombit index            | 4.57 GiB   |   11050258 |
| Key-Value store       | Log search index          | 80.00 B    |          3 |
| Key-Value store       | Contract codes            | 9.62 GiB   |    1545294 |
| Key-Value store       | Hash trie nodes           | 0.00 B     |          0 |
| Key-Value store       | Path trie state lookups   | 96.17 KiB  |       2402 |
| Key-Value store       | Path trie account nodes   | 44.69 GiB  |  387079001 |
| Key-Value store       | Path trie storage nodes   | 172.86 GiB | 1720525876 |
| Key-Value store       | Verkle trie nodes         | 0.00 B     |          0 |
| Key-Value store       | Verkle trie state lookups | 0.00 B     |          0 |
| Key-Value store       | Trie preimages            | 0.00 B     |          0 |
| Key-Value store       | Account snapshot          | 12.96 GiB  |  283406617 |
| Key-Value store       | Storage snapshot          | 91.63 GiB  | 1269738120 |
| Key-Value store       | Beacon sync headers       | 1.21 KiB   |          2 |
| Key-Value store       | Clique snapshots          | 0.00 B     |          0 |
| Key-Value store       | Singleton metadata        | 695.72 KiB |         16 |
| Light client          | CHT trie nodes            | 0.00 B     |          0 |
| Light client          | Bloom trie nodes          | 0.00 B     |          0 |
| Ancient store (Chain) | Headers                   | 10.54 GiB  |    6555000 |
| Ancient store (Chain) | Hashes                    | 800.62 MiB |    6555000 |
| Ancient store (Chain) | Bodies                    | 385.42 GiB |    6555000 |
| Ancient store (Chain) | Receipts                  | 120.87 GiB |    6555000 |
+-----------------------+---------------------------+------------+------------+
|                                   TOTAL           | 868.21 GIB |            |
+-----------------------+---------------------------+------------+------------+

[rjl493456442]

Snap sync with --chain.history=all

+-----------------------+---------------------------+------------+------------+
|       DATABASE        |         CATEGORY          |    SIZE    |   ITEMS    |
+-----------------------+---------------------------+------------+------------+
| Key-Value store       | Headers                   | 55.82 KiB  |         88 |
| Key-Value store       | Bodies                    | 6.42 MiB   |         88 |
| Key-Value store       | Receipt lists             | 6.73 MiB   |         88 |
| Key-Value store       | Difficulties (deprecated) | 0.00 B     |          0 |
| Key-Value store       | Block number->hash        | 3.61 KiB   |         88 |
| Key-Value store       | Block hash->number        | 863.83 MiB |   22092480 |
| Key-Value store       | Transaction index         | 13.39 GiB  |  388578627 |
| Key-Value store       | Bloombit index            | 4.57 GiB   |   11050258 |
| Key-Value store       | Log search index          | 203.38 MiB |    2135822 |
| Key-Value store       | Contract codes            | 9.62 GiB   |    1545294 |
| Key-Value store       | Hash trie nodes           | 0.00 B     |          0 |
| Key-Value store       | Path trie state lookups   | 76.79 KiB  |       1918 |
| Key-Value store       | Path trie account nodes   | 44.69 GiB  |  387071252 |
| Key-Value store       | Path trie storage nodes   | 172.86 GiB | 1720536779 |
| Key-Value store       | Verkle trie nodes         | 0.00 B     |          0 |
| Key-Value store       | Verkle trie state lookups | 0.00 B     |          0 |
| Key-Value store       | Trie preimages            | 0.00 B     |          0 |
| Key-Value store       | Account snapshot          | 12.96 GiB  |  283408241 |
| Key-Value store       | Storage snapshot          | 91.63 GiB  | 1269744950 |
| Key-Value store       | Beacon sync headers       | 619.00 B   |          1 |
| Key-Value store       | Clique snapshots          | 0.00 B     |          0 |
| Key-Value store       | Singleton metadata        | 394.43 MiB |         19 |
| Light client          | CHT trie nodes            | 0.00 B     |          0 |
| Light client          | Bloom trie nodes          | 0.00 B     |          0 |
| Ancient store (Chain) | Receipts                  | 237.47 GiB |   22092393 |
| Ancient store (Chain) | Headers                   | 10.54 GiB  |   22092393 |
| Ancient store (Chain) | Hashes                    | 800.62 MiB |   22092393 |
| Ancient store (Chain) | Bodies                    | 629.05 GiB |   22092393 |
| Ancient store (State) | History.Meta              | 147.75 KiB |       1915 |
| Ancient store (State) | Account.Index             | 17.96 MiB  |       1915 |
| Ancient store (State) | Storage.Index             | 22.97 MiB  |       1915 |
| Ancient store (State) | Account.Data              | 19.03 MiB  |       1915 |
| Ancient store (State) | Storage.Data              | 7.55 MiB   |       1915 |
+-----------------------+---------------------------+------------+------------+
|                                   TOTAL           |  1.20 TIB  |            |
+-----------------------+---------------------------+------------+------------+

[zsfelfoldi]

Sorry, I accidentally closed this PR instead of my own.

[fjl]

I didn't run this, but it did run successfully before.

One aspect of this change that took me a while to understand is the removal of the sidechain deletion in InsertReceiptChain. With these changes, we will now insert headers, block bodies, and receipts in a single batch directly into the freezer. We previously had quite a bit of code to handle divergence between the downloader header chain and the body items, i.e. there could be sidechains during sync. By combining the writes into a single batch, this condition can no longer occur, and thus it is safe to remove the cleanup logic.