implement a proper relay v2 search strategy

[Jorropo]

Description

Our current relay search is pretty bad.
It just constantly poll our K cluster with some exp-backoff.

The goal of this is to avoid convergence on a few nodes and spread the relaying load more or less evenly on all reachable dhtservers.

However the actual strategy we were supposed to implement is an outward search until success. If no nodes in our K cluster support relaying, it probably will never change.

Maybe a random polling of the DHT is not that bad after all ?

API

Currently this is implemented with a long running task, this would need to be rewriten to be statefull and executing in the libp2p callback.

[lidel]

Some notes for the future:

• bump go-libp2p v0.22.0 & go1.18&go1.19 #9244 switched to go-libp2p v0.22 which is no longer expecting Kubo to inform go-libp2p about new peers via periodically push, but instead go-libp2p performs a pull via defined peer source func, and does it only when needed.
  • autorelay.WithPeerSource is wired up here, but it uses the old autoRelayFeeder from here.
    • This "feeder" was designed around periodically informing libp2p about new peers (Kubo pushing new peers to go-libp2p), which is no longer how things work, and is probably wasteful.
• relayFinder from go-libp2p 0.22 will ask peerSource func for more and more peers in batches of maxCandidates until findNodes finds a relay. This opens some questions:
  • Should Kubo keep a state about what was provided via peerSource?
  • Should we send Peering.Peers first? (if any)
  • Should we trigger a random DHT walk if all known peers are already sent, but go-libp2p asks for more?

[Jorropo]

Should we trigger a random DHT walk if all known peers are already sent, but go-libp2p asks for more?

No in theory this isn't good because it would lead to network convergence on better nodes.
In theory a outward DHT search is better

Should Kubo keep a state about what was provided via peerSource?

I think so else how do you know how wide do you need to hit ?

[Jorropo]

Actually we don't need an outward DHT search, we just need a repeatable random pattern (for example hashing the previous key searched).