feat: update relay protocol to iroh-relay-v2, add new Health frame, test protocol update mechanism

[Frando]

Description

This branch add a iroh-relay-v2 protocol. The only changes to the iroh-relay-v1 protocol are:

• removed Health frame (id 11) with string payload
• added Status frame (id 13) with binary-encoded enum payload that can be extended with further variants or payloads
• From now on, unknown frames will be ignored in iroh (instead of erroring out)

I wrote this mostly as a test case if and how we can update the relay protocol in a backwards-compatible way. Not sure if the new Health frame is worth it. But also, maybe it's a good idea to actually put the version negotiation and upgrade mechanism to test before we release 1.0?

The PR likely needs some more cleanups. But would be interested in a high-level review/discussion if this is roughly how we intend to support backwards-compatible relay protocol changes during 1.0.

Breaking Changes

Notes & open questions

Change checklist

• Self-review.
• Documentation updates following the style guide, if relevant.
• Tests if relevant.
• All breaking changes documented.
  • List all breaking changes in the above "Breaking Changes" section.
  • Open an issue or PR on any number0 repos that are affected by this breaking change. Give guidance on how the updates should be handled or do the actual updates themselves. The major ones are:
    • quic-rpc
    • iroh-gossip
    • iroh-blobs
    • dumbpipe
    • sendme

[ramfox]

doesn't declaring them in this order would mean calls to max would return V1 rather than V2 (which we call in handle_relay_ws_upgrade) (since we derive Ord)

[Frando]

good observation, thanks. changed and added a test for the protocol negotiation.

[ramfox]

only addition I might add here something on the client side that acknowledges we negotiated the protocol. Maybe just a debug line at this point, since it's not used anywhere on the client side yet?

[matheus23]

I wrote this as feedback in discord, but that's quickly lost to the archives, so just repeating some higher-level feedback here:

My thinking was that we should separate our protocol versions by module. So e.g. now, we'd introduce two modules: iroh-relay/src/protos/{v1,v2}/proto.rs, etc. There's probably some thinking needed to figure out if we want to duplicate common.rs as well/if there's a way of extracting only the useful stuff from it, but otherwise that's roughly what I'm thinking.

If we do this, it is much easier to look at one protocol and see how it works rather than mixing multiple versions in the same code. I think that can become quite messy.

It's also nice to be able to have a bunch of #[cfg(feature = "iroh-relay-v1")] pub mod v1; and similar in protos.rs. This would then eventually make it possible to reduce code size if that becomes a concern.

[github-actions]

Netsim report & logs for this PR have been generated and is available at: LOGS
This report will remain available for 3 days.

Last updated for commit: 82d2df9

[matheus23]

Let's ship this - at the very least for the important bugfix.

Let's discuss changes to code structure later and open another PR for those if need be.