feat(l1): only use negotiated capabilities

[Mechanix97]

Motivation

We need a way to ensure what version of a protocol we're using when communicating with a peer.

Description

Important

After merging this PR, we can merge this other PR from the hive repository, which adds updates the devp2p simulator to include the latest test suite.

When the connection is established with the peer we agree in the p2p protocol version (as default n 5). This happens after the handshake is done.

Then we exchange the hello messages, where we coordinate with the peer which protocols we're using. Once we agree on them, we store them in the Capabilities struct (which is shared with the RLPxCodec behind an Arc<Mutex<>>.

The codec has the responsability to generate the messages to send the peers and decode the messages we receive. Now, the p2p,eth and snap protocols agreed with the peers are stored in the Capabilities struct. So when we need to encode/decode we know which version of the protocol has to be used.

Note

TO DO:
The Capabilities struct is accessed from the RLPxCodec in the encode and decode functions.

However the encode and decode functions are sync, while accessing the Capabilities is async (since we need to lock the mutex with self.capabilities.lock().await).
The problem is that, even though the functions are sync, they are executed within an async context, so we cannot use block_on (we actually have tried that and the thread just crashes), so we need to find a way to fix this.

The logic of the code offset has been improved to support differents version of the same protocol. For example, in the eth/69 version a new message is added, so the offset of the snap suite changes depending of which version of the protocol we are using.

To allow the messages from different versions to be more differentiated, the Status and Receipts enums were removed and now the structs Status68, Status69, Receipts68 and Receipts69 are used directly (each of them implementing the RLPxMessage trait).

Much of the code introduced in the PR #2860 was removed. Only the encode/decode of status and receipt was left. The file struct created has also been deleted.

Closes #3032

[mpaulucci]

why are we passing this here?

[ricomateo]

The parameter p2p_protocol (along with eth_protocol and snap_protocol) is used inside Message::encode to encode the message header.

However the header could be encoded just before calling Message::encode, which would allow us to remove the p2p_protocol and snap_protocol parameters, it could be something like this (we still need to pass eth_protocol to encode the message according to the right eth capability)

// Header encoding
(message.code() + message.offset(
    &self.p2p_protocol,
    &self.eth_protocol,
    &self.snap_protocol)?
).encode(&mut frame_data);

message.encode(&mut frame_data, &self.eth_protocol)

What do you think? do you prefer doing the header encoding of Message::encode?

[mpaulucci]

Closing since this hasn't been worked on in some time. But we will use this PR as reference for when we work on this again.