Allow encouraging (or forcing) dials with specific properties

[aschmahmann]

What

The current contract around Connect and NewStream delegates basically all control over how to form the connection to go-libp2p. This is a feature request for additional capabilities indicating a preference of how a connection might be formed.

Why

For example:

• What if a user felt that for some workloads they'd prefer TCP over QUIC despite some of the tradeoffs (e.g. if TCP throughput exceeds QUICs for some data transfer heavy workloads)
• What if a user knew that a particular network interface happened to be faster/cheaper for them (e.g. addresses in the same cloud provider network)
• What if a user wanted to do some debugging using a node with lots of transports supported, but only wanted to use one of them
  • This is effectively the issue in swarm connect will use any available address not just the given multiaddress ipfs/kubo#9895
    • Note: As mentioned in that issue doing debugging this way can be difficult and doing debugging in that particular way likely has issues beyond the go-libp2p ones. Feedback welcome if you feel I've missed anything in swarm connect will use any available address not just the given multiaddress ipfs/kubo#9895 (comment)
  • IIUC to some extent AutoNAT could operate this way, but we're ok spinning up a slimmed down separate host anyhow for these shortlived operations and "just make a new host" ends up being the required pattern for other sorts of services like this. It's not clear to me whether this pattern being mandatory is deemed a hack or intended. It feels a little like the former though.

How

The three mechanisms I'm aware of that can enable this are:

1. For pass/fail type behavior it might be possible for this to exist in user-space with some hackery around connection gaters, except for the fact that we might return if there is already a connection open.
2. Information could be passed into the dialer via contexts, such as more versions of

   go-libp2p/core/network/context.go

   Line 28 in cfc50ba

   func WithForceDirectDial(ctx context.Context, reason string) context.Context {

3. Using some overriding of the dialer logic with something explicit, like

   go-libp2p/options.go

   Line 581 in cfc50ba

   func DialRanker(d network.DialRanker) Option {

4. More functions on the host that have explicit guarantees

None of these are enough as-is today to implement the above, however it seems likely some combination 2 + 3 would be able to get the job done.

For example, if either the DialRanker could take a context or the context could carry a custom dialer then most of the logic here could live in application space. There could also be a similar type of configuration around contexts for if a new connection should be used and a ConnectionRanker.

Why (file this issue) Now

I haven't heard a ton of requests for these features although they do come up from time to time. However, the coincidental timing of the linked kubo issue (from someone familiar with go-libp2p and kubo 😄) and the recent smart-dialer work made me think this could be useful to put on the radar in case it ends up being easier to make changes to now rather than later (e.g. should the DialRanker take a context, and should it be overridable on a per Connection/Stream basis).

[MarcoPolo]

Thanks for the detailed issue. Off the top of my head, having a context option that can override some dial ranking logic seems reasonable to me.

[marten-seemann]

However, the coincidental timing of the linked kubo issue (from someone familiar with go-libp2p and kubo 😄)

I think I saw that issue ;)

This should probably be part of a larger redesign of the swarm (and the Connect) API. We definitely should make it possible to dial addresses without consulting the peerstore.