Rebase statediffing geth onto v1.10.18

[i-norden]

1.10.18 has been released, we need to update our custom geth client to work on top of this release.

We need to perform the rebase for both the v3 and v4 versions

• v3 on top of https://github.com/vulcanize/go-ethereum/tree/v1.10.17-statediff-v3 (from that branch, git checkout -b v1.10.18-statediff-3.2.1)
• v4 on top of https://github.com/vulcanize/go-ethereum/tree/v1.10.17-statediff-v4 (from that branch, git checkout -b v1.10.18-statediff-4.0.1-alpha)

After cutting a release, we will to update the following repos to use these releases:

• Rebase to v1.10.18 versions of vdb geth eth-statediff-service#87
• Rebase to v1.10.18 versions of vdb geth  ipld-eth-server#158
• Rebase to v1.10.18 version of vdb geth vulcanize/migration-tools#16
• Rebase to v1.10.18 versions of vdb geth ipld-eth-db-validator#6
• Rebase to v1.10.18 versions of vdb geth ipld-eth-state-snapshot#37
• Rebase to v1.10.18 versions of vdb geth eth-statediff-fill-service#3

We will also need to update and release versions of the following repos that use the root v1.10.18 release:

• Rebase to v1.10.18 of root geth ipfs-ethdb#34
• Rebase to v1.10.18 of root geth leveldb-ethdb-rpc#10
• Rebase to v1.10.18 of root geth go-eth-state-node-iterator#12
• Rebase to v1.10.18 of root geth eth-ipfs-state-validator#23

Some changes that necessitate changes in our stack, aside from rebasing our release of this repo and propagating those:

• Tracing API was broken (core/vm: for tracing, do not report post-op memory ethereum/go-ethereum#24867, internal/ethapi: add refund to StructLogRes ethereum/go-ethereum#24567, eth/tracers/logger: use omitempty to reduce log bloat  ethereum/go-ethereum#24547) this likely results in changes that need to be reflected in https://github.com/vulcanize/tracing-api
• Ancient interface was broken (renaming of constituent interfaces) and extended in: core/rawdb: untie freezer and ancient chain data ethereum/go-ethereum#24684. When rebasing ipfs-ethdb and leveldb-ethdb-rpc to v1.10.18 this will necessitate making some minor changes/additions to the interface implementations there

Somethings that potentially warrant further discussion:

• This release uses go 1.18, and uses some features only present in 1.16+, further supporting our desire to move everything up to 1.18
• The new trie tracing/state diffing supports intermediate nodes and delete nodes, it only tracks the path of the nodes but this could potentially be extended to replace our auxiliary statediffing service. What they've implemented is very similar to the cache wrap listener we have implemented for the SMT. trie, les, tests, core: implement trie tracer ethereum/go-ethereum#24403
• Ropsten total difficulty for the Merge has been coded in
• Rinkeby testnet has been deprecated
• Apparently eth_getProof wasn't actually working for storage nodes until this release: core/rawdb: untie freezer and ancient chain data ethereum/go-ethereum#24684

[i-norden]

So the first step is creating the new releases here, the next step will be to work through all the linked issues/repos, find the ones that are next in the dependency tree (aka there is no note in the issue that you will/may also need to update dependency on another repo as well; e.g. ipfs-ethdb, go-eth-state-node-validator, leveldb-ethdb-rpc) and perform those updates and releases, and then move up the dependency tree to repos which depend on the new release of vdb geth + other repos that were updated in the previous step.

[abdulrabbani00]

@i-norden - We might want to tackle this ticket as well: #181

I would create a pipeline using the stack orchestrator, similar to: https://github.com/vulcanize/ipld-ethcl-indexer/blob/main/.github/workflows/on-pr.yml#L32

[abdulrabbani00]

I have created two releases:

1. https://github.com/vulcanize/go-ethereum/releases/tag/v1.10.18-statediff-3.2.1
2. https://github.com/vulcanize/go-ethereum/releases/tag/v1.10.18-statediff-4.0.1-alpha

I tested both by utilizing the stack orchestrator. It was straightforward for v3 but I had to hack together a solution using the new migration process in v4.

To validate I did the following:

1. Ensure geth started up.
2. Mined a new block.
3. Checked to see if the block was populated in the eth.header_cids table.