New Dialer

[Stebalien]

The direct connection rework introduced two bugs in the dialer and exposed a variety of issues.

1. Prefer non-transient connections over transient connections when opening new streams. Otherwise, we could miss a usable connection.
2. Do not use the first dial's context to derive the "dial once" context when dialing. Otherwise, canceling this context can cancel subsequent (joined) dial attempts.

2 is actually pretty common. If I try to make two requests to a peer a the same time, then decide to cancel the first, the second request will get canceled.

---

Requirements to fix the situation:

1. Add tests. We need a test for both of these cases. We need a test for the first case. We had a test for the second case and ignored failing CI.
2. Figure out the correct approach to 2. Here, I'm just reverting the current behavior but this revert will break direct connection support.

A better implementation of 2 is to have new dials "join" an active dial by sending an address filter function to the active dial over a channel. The channel would then:

1. Go back through previously "filtered" addresses and see if any of them are allowed by this new function. If so, add them on to the end of the "to dial" channel.
2. Whenever a connection attempt succeeds, the active dial worker would look through the address filter functions sent by all "joined" dials and send the new connection back to any caller where the filter function passes.

This is my preferred approach.

We could also consider approaches where:

1. We could make a new context but copy the options over. This is still wrong, but at least it's less broken.
2. If our options differ with an active dial, we could wait for that active dial to finish. This is slow, but the simplest and least wrong approach.

But given that we now have multiple people working on this project, I'd much prefer to go with the correct approach.

---

The new dialer was implemented in #250 .

[vyzo]

We also need to figure out a mechanism to pass down context options to the transport where applicable.

[vyzo]

For instance, in libp2p/go-libp2p-quic-transport#194 we do make use of the SimultaneousConnect context option to have one side punch a hole, which is quite important for a successful hole punch.

[Stebalien]

We also need to figure out a mechanism to pass down context options to the transport where applicable.

That will depend on the option. The simplest is to just let the first to dial win. That should work for the "active listen" case and is probably our best option.

Unfortunately, that doesn't work so well for the direct connection case because the two different dials have two different requirements.

[vyzo]

The test failure was the flaky connection gating test; see #251.