Have an upgrade strategy for the network protocol

[tomaka]

The network protocol (the data structures in network/src/message.rs) changes from time to time, but we don't have any upgrade strategy. If the networking changes, we will suddenly start dropping peers that don't use the same version.

There is a protocol_version variable in the source code, but modifying it makes us instantly incompatible with nodes having a different version.

Libp2p has a version negotiation system that makes it possible to support multiple version at the same time, but we don't benefit from it.

How to do that without bloating the code is however unclear.

[arkpar]

Fixed in #1811

[tomaka]

That's not really what I had in mind. If we modify the Message struct, we still break the network protocol. The source code should be organized in a way to make it easy to continue supporting old versions.

[arkpar]

#1811 Adds min_supported_version to the Status packet and changes the version check. This allows nodes to declare that they support backwards compatibility.

[tomaka]

Yeah, we have some networking mechanism, but there's no reasonable way in the source code to support two different versions. If someone wants to modify Message, having to maintain backwards compatibility is a daunting task.

[gavofyork]

encoding Header with serde is not the answer. we could encode the non-runtime datastructures with codec and then use serde on the network-specific data structures that includes them, i guess.

[tomaka]

encoding Header with serde is not the answer. we could encode the non-runtime datastructures with codec and then use serde on the network-specific data structures that includes them, i guess.

That's exactly what I wanted to do in #2011