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)

The actual change is thus quite minor, but serves as a real-world test for our protocol negotiation.

The PR also fixes a bug in how the relay server parsed the supported protocols; it is harmless because all existing deployments support a single version anyway, but good to fix now.

Everything is fully backwards-compatible on the wire (old clients can talk to new relays, and new clients can talk to old relays).

Breaking Changes

• iroh_relay::http::RELAY_PROTOCOL_VERSION has been removed. The relay protocol now supports version negotiation between client and server. Use iroh_relay::http::ProtocolVersion instead. For the previous constant value, use ProtocolVersion::V1.to_str().
• iroh_relay::server::client::Config has a new field protocol_version: ProtocolVersion.
• iroh_relay::protos::relay::RelayToClientMsg has a new Status(Status) variant and the existing Health variant is deprecated. Clients should handle RelayToClientMsg::Status for connection health information. The Health variant is still sent by V1 relay servers but should not be relied upon going forward.

Notes & open questions

Change checklist

• Self-review.
• Documentation updates following the style guide, if relevant.
• Tests if relevant.
• All breaking changes documented.

[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.

[matheus23]

From now on, unknown frames will be ignored in iroh (instead of erroring out)

Hmmm. I'm sorry I just reread the PR description again and that's why I'm coming back to this.

We should reconsider this (after merging!). We can always change this IMO, that's not a problem, as long as we change this before we do the next breaking change without adding another relay protocol version (and I think we'll always want to use a new protocol version even if we add optional frames).

This is contrary to what e.g. QUIC does: If you receive a frame you don't know - that's a protocol violation.

We should really think through what this means in various cases again before we do the next protocol change.

[Frando]

This is contrary to what e.g. QUIC does: If you receive a frame you don't know - that's a protocol violation.

Good point. I think you are right and we should fix that. I'll look into it.