command message versioning

[Geal]

The command protocol for the proxy does not include version numbers. Incremented version numbers should be fine.
How can we keep the protocol backward compatible?

[Geal]

version number added in 086d08c, but not checked yet

[Geal]

in 2278726 we check if we receive a message with a higher version number.

Side note: what happens if someone updated sozu and sozuctl at the same time, the configuration protocol has changed, and they use the upgrade command? sozu might refuse that message.
ideas:

• do not refuse an upgrade message even if the version is not the right one (problem: what if we want to change the upgrade message)
• have sozuctl support different versions of the configuration language (which will already happen in the command lib anyway), so it can send a message with a lower version if necessary

[Geal]

Copying the message from #240 to have everything in one place:

Configuration messages hold a version number, that should be used when parsing messages, since people might use an older tool with a new version of sozu.

The solution would be based on serde's tagged enum feature: serde-rs/serde#745 (a PR is currently in progress for this: serde-rs/serde#973 )

Here's how the code would change in command/src/data.rs:

first define a ConfigMessageWrapper enum:

#[derive(Debug,Clone,PartialEq,Eq,Hash,Serialize,Deserialize)]
#[serde(tag = "version")]
pub enum ConfigMessageWrapper {
  #[serde(rename = "0")]
  V0(ConfigMessageV0),
  #[serde(rename = "1")]
  V1(ConfigMessage),
}

The latest version is always the currently used ConfigMessage. ConfigMessageWrapper implements Into, so we need a way to transform a V0 message in a V1 one. It also has a function to get the version number.

Duplicate the assets in command/assets, so that we have subfolders for v0, v1, etc.

When the master parses messages, it will get the version number and hold onto it in the Client structure, to answer with the same version number.

Until the version 1.0 of sozu is released, the message format will have breaking changes, so for now the version number stays at 0.

The related serde issues did not advance since September. If someone wants to help them, that would be nice

[Geal]

it might be a good idea to reuse an approach like serde-rs/serde#880
versioning is unfortunately an issue when upgrading sozu, as seen in #364

[Geal]

we should make a clear policy for this in sozu 0.14, and make it testable in the command lib code. Major version upgrades should be easier to do