WIP: Implement eth/66

[cburgdorf]

What was wrong?

We need an implementation of eth/66 to support our proposed EIP.

How was it fixed?

1. Changed the commands to contain the RequestID according to the EIP
2. Validate early in the response chain that the RequestID matches our expectations (This is the part that improves overall processing capacity)
3. Changed the send_get_xx methods on the ETHAPI to return the created request id
4. Changed the send_xx methods to take in a request id to include it in the response

To-Do

• Clean up commit history

• Add entry to the release notes

Cute Animal Picture

[holiman]

Hey, why no merge?
Let's play; ethereum/go-ethereum#22241

[holiman]

Look at these poor guys -- one goerli node and one mainnet node, who are both advertising only eth66. They've been trying to find friends for several hours now, but there's nobody who wants to play with them.

[cburgdorf]

Hey Martin, I'm excited to see this finding its way into Geth! When I originally wrote this PR it wasn't entirely clear if others would follow quickly to adapt the new protocol and so we let it wait unmerged and other more pressing issues took our attention. Meanwhile I have left Trinity development and moved on to work on a new EVM lang instead (https://github.com/ethereum/fe).

Citing from the Ethereum blog Trinity development is winding down.

The Trinity team is winding down development on the Trinity Ethereum client in order to re-focus on more impactful problems with the core protocols.

I'm not 100 % sure if the plan is to retire the client entirely or not so I'll copy in @carver and @pipermerriam who would be the best to know about the current plan for Trinity development. Especially since this is a protocol change to be adapted by other clients it may still be interesting for their new focus.

[holiman]

When I originally wrote this PR it wasn't entirely clear if others would follow quickly to adapt the new protocol and so we let it wait unmerged and other more pressing issues took our attention.

I see. Well, for geth, we reasoned that we wouldn't be able to take advantage of all the upsides until a lot later, so it would add a lot of handling but wouldn't allow us to remove the old code paths.

Since we have a hardfork coming, we want to get eth66 support in before that, so that all (geth) berlin clients are guaranteed to support it, giving us the option to drop <66 support later on.

[big-c-note]

Popping in here to say that I would contribute if Trinity is NOT being retired and you all want to move to the eth 2 specs. I believe that started here, https://github.com/ethereum/trinity-eth2, but has also gone stale it seems