feat!: add iroh-relay crate

[divagant-martian]

Description

Adds a new crate iroh-relay. It's structured as follows:

• protos: protocols the server is able to handle, this includes the relay protocol, stun, and partially disco.
• server: the server code, as it was already in the og mod
• client: the client code, as it was already in the og mod
• server binary (bin iroh-relay) as it was previously in iroh-net's bin.

This moves the code around in the least disruptive possible way to give us a starting point over which to improve this. Check the notes and open questions for future work

Breaking Changes

• iroh_net::relay is removed. RelayUrl, RelayMode, RelayNode and RelayMap are moved to the top (iroh_net). All other members of this module are now moved to the new crate iroh-relay

Notes & open questions

• Disco includes a transaction id defined in terms of stun's transaction id. Every use of this is now directly from stun_rs to make it clear this is not defined in terms of the relay's stun server. The relay can't read the contents of disco packages so I consider this the right thing to do, even if the types are actually the same.
• The relay needs to identify Disco packages to queue them separately. Disco is not yet its own crate because we do not know its future. Based on this I chose to duplicate the code that does the identification. But just this signals we should start the work on deciding what disco looks like in a post ts world to de-duplicate this code and use it from a single source. The code as it stands is highly unlikely to change; however, any change to the protocol's wrapper would now need to be changed in two places, which is ofc not ideal.
• The relay's "protocol" includes quite a lot of non protocol code, that probably belongs more to the server. I was really tempted to try to move this code to better places but in reality this is not the time. The purpose of this PR is among many others, to allow for future work like this.
• What used to be called the relay module had a lot of relay-related code without a clear objective or offering. This includes for example, all the relay map related code. The relay as a protocol, server, and client, has absolutely no need for these types. Relay topology is entirely a iroh/iroh-net topic. On the same page is the infra-related code. Nothing in the protocol, server or client is different depending on the infra values. This is entirely a iroh/iroh-net topic. Based on these arguments, these types, functions, etc that were part of the relay module have actually stayed in iroh-net instead.
• I did a couple passes of udeps, but it's messy. Optional dependencies are their own feature so they aren't flagged as unused. There are (in general, not in the relay) dependencies that differ in targets, and the features combinations also affect this as well. So the deps that remain are a "reasonable best effort" in accordance with our CI checks. In reality, - and in particular when checking feature combinations with fc - there's a lot of work left to do on that front.
• The crate's version is 0.29 because there's no point in setting the version to 0.28, which will never be released, to then later be changed to 0.29. This might be unexpected but it's the option that reduces senseless future work.
• dns code is duplicated. This is unfortunate but since it's only used in tests to configure the client there's really not much to do here. Most of what this does are fixes we should try to upstream

Change checklist

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

[matheus23]

Some (perhaps optional) nits, but I'm happy with this overall :)

cargo deny is not happy, but not much we can do about it right now.

[dignifiedquire]

please make the version 0.28, because when I run the release with cargo-release, bumps all happen automatically and if it is 0.29 I need to manually exclude the crate

[flub]

please make the version 0.28, because when I run the release with cargo-release, bumps all happen automatically and if it is 0.29 I need to manually exclude the crate

I'm surprised this needs to be in sync? I thought the reason to split these crates out was so they could stay <1.0 while the main crates get 1.0. Short term of course this doesn't matter.

[dignifiedquire]

I'm surprised this needs to be in sync?

my goal for now is to keep all iroh-* crates on the same version until we are in more stable waters