swarm: dial DNS addresses in parallel with IP addresses

[sukunrt]

We dial a peer after resolving any dns addresses of the peer. We should dial the IP addresses and resolve the dns addresses in parallel.

[marten-seemann]

That's a good point. I imagine that DNS addresses will become more prevalent once we enable libp2p+HTTP services, so resolving this will become even more important in the future.

Two questions:

1. How exactly will the prioritization logic look like? For example, we might know the TCP addresses, and receive some QUIC addresses from DNS? We probably don't want to cancel the TCP dial attempt. Would we now start a QUIC dial right away? Might make sense to do so in the case of QUIC. However, what if we only knew an IPv4 address and now receive an IPv6 address? Probably not worth it in that case.
2. I'm curious how this interacts with DNS caching. We will run into this when we dial the same peer multiple times (or, less likely, if multiple peers share a domain name). When using our DoH resolver, it might make sense to introduce a "only if cached mode" for our lookups. That would allow us to do the dial prioritization with the complete set of addresses, instead of starting dials with a smaller subset, and then adding the resolved addresses half a millisecond later.

[sukunrt]

I think this is a good start.

1. From the list of peer addresses, resolve all dns addresses only from cache.
2. Rank the IP addresses that we have
3. Begin dialling the IP addresses according to the ranking logic. In parallel, begin resolving the DNS addresses
4. Add addresses from DNS resolution to the dial queue.
   a. If TCP dials are in flight we ignore the inflight dials and proceed to dialing the received addresses right away based on the dial prioritisation logic. So if we received two new QUIC addresses and a new TCP we will dial one of them immediately and wait 250ms and then dial the next one and then 250ms later dial the TCP address.
   b. If a QUIC dial is in flight we delay the new address dials by 250ms wrt the start of the QUIC dial in flight. Here we ensure happy eyeballs, if a QUIC IPv6 dial is in flight we rank received QUIC IPv4 higher than QUIC IPv6. If a QUIC IPv4 dial is in flight we rank the received IPv6 address higher than the IPv4 address.
5. Keep dialling addresses from the dial queue.

NOTE: This ignores the recommendation from the Happy Eyeballs RFC to wait 30ms for receiving a AAAA record after receiving an A record when resolving the dns address. We can take that up after we have this in place.

I'm not completely sold on resolving DNS in parallel with IP addresses. We can wait also wait for 250ms if some QUIC dials are in progress before beginning DNS resolution. But doing DNS resolution in parallel makes the algorithm much simpler.