feat: Attempt at a Relay Manager

[dariusc93]

This is an attempt at a relay manager that would allow auto relay. This operates as its own behaviour that would have candidates injected into it that supports STOP protocol (assuming that the interpretation of the spec is correct) and would utilize one with the lowest ping. The implementation is only basic and a PoC, but does have a bit of a feel of what might be the best way to handle it (although we might need to rethink the logic)

Related to #4

Enabling the relay flag will be all one would need to do for now. Eg

use rust_ipfs::{IpfsOptions, TestTypes, UninitializedIpfs};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    tracing_subscriber::fmt::init();
    let opts = IpfsOptions {
        relay: true,
        ..Default::default()
    };

    let ipfs = UninitializedIpfs::<TestTypes>::new(opts)
        .spawn_start()
        .await?;

    ipfs.default_bootstrap().await?;
    tokio::spawn({
        let ipfs = ipfs.clone();
        async move {
            ipfs.bootstrap()
                .await
                .expect("bootstrap would have been restored with Ipfs::default_bootstrap");
        }
    });

    let identity = ipfs.identity(None).await?;
    println!("PeerID: {}", identity.peer_id);
    loop {
        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
    }
}

Note:

1. While it does select the relay, there seem to be issues with the connection being establish so we arent able to establish a connection to the relay peer externally (over the internet) right away. This may be due to the addresses containing a double p2p (eg /ip4/147.75.61.171/tcp/4001/p2p/12D3KooWQgmve2ZyEUWkLDJQPDk51fLh7NrxN3wMBhxrGAeKKs26/p2p-circuit/p2p/12D3KooWD53eviVdfDp6yCV6KwUpRMvTBRZw848wMmVebPWwJVcS/p2p/12D3KooWD53eviVdfDp6yCV6KwUpRMvTBRZw848wMmVebPWwJVcS), that it may take a longer or may need to expand on the logic when trying to get a reservation to determine if the relay is the best choice.
2. Logic is incomplete and likely will just use this as a PoC and would aim for a rewrite for something suitable but only to give a idea of what should be done (meaning this PR may not even get merged)
3. Due to the behaviour not being able to get the remote protocol, we will rely on injecting the peer that support that the protocol we are looking for (which in this case may be STOP but could be wrong)
4. Changes will be made to possibly receive info from autonat to determine if the peer is discoverable publicly (it does uses NatStatus but not any extended checks but may want to rid of using that directly) and possibly

Question:

1. Should we be looking for peers that support relay v2 HOP instead?

[dariusc93]

The behaviour was moved to its own repo at https://github.com/dariusc93/libp2p-autorelay