Some ETH Protocol changes to prepare the room for eth/66

[cburgdorf]

What was wrong?

This is a fall out from #1672 which implements the upcoming eth/66 protocol. This PR contains only a few cleanups that should make #1672 cleaner and easier to read.

How was it fixed?

1. Changed the NormalizerAPI API to make normalize_result non-static and hence allow better code reuse with the introduction of a DefaultNormalizer. To elaborate, I believe the only reason why we even have the NormalizerAPI is the is_normalization_slow property. If not for that, we could simply allow a function be used instead of implementing NormalizerAPI. But considering that we need to implement classes for the NormalizerAPI, it feels like an extra burden that we effectively dissallow constructor usage by forcing normalize_result to be static. This leads down a road of having to implement classes that are mostly copy and paste with just tiny differences.

Making normalize_result non-static gives us more flexibility and allows us to use one normalizer for common scenarios e.g:

DefaultNormalizer(BlockHeadersV65, Tuple[BlockHeaderAPI, ...])
DefaultNormalizer(PooledTransactionsV65, Tuple[SignedTransactionAPI, ...])
DefaultNormalizer(BlockHeaders, Tuple[BlockHeaderAPI, ...], normalize_fn=lambda res: res.payload.headers)

2. Renamed protocol types that were not versioned and which become obsolete in ETH/66 to contain a V65 version flag.

3. Made sure some of our tests operate on all the different ETH protocols that we support. The biggest change here is that the ETHPeerFactory will use the supported_sub_protocols property of the peer to set the highest protocol on the ETHHandshaker.

4. Removed some intermediate variables in eth/commands.py as I felt they are making the code harder to parse when some of these commands become a V66 counterpart (not part of this PR but can be seen in WIP: Implement eth/66 #1672)

To-Do

• Clean up commit history

• Add entry to the release notes

Cute Animal Picture

[gsalgado]

LGTM, just one question

[gsalgado]

Do we return v63 because that's the oldest version and we want to try only the oldest and newest? Maybe add a comment to that effect?

[cburgdorf]

The ETHV63Handshaker is only for V63 as it uses a different Status command. The ETHHandshaker is used across all versions above V63. However, it takes in highest_eth_protocol to be able to tell the other side our highest supported protocol version. But even if we report V65 as the highest version and we are faced with another peer that only supports V64, we'll end up doing the handshake with ETHHandshaker in that case.

[cburgdorf]

I'm going to add a comment in the source.