This isn't working as we want yet in several regards but putting a progress commit in here.
Overall:
- Needs offload to a sibling connection (and option governing this)
- Needs to fail much faster in the initial connection scenario
- Lots of test love around the new functionality

default subtly differs here in that the reader/writer states will default to int/byte 0 which is not the same as NA. Perhaps we should just make NA be the 0 state though, which would simplify all use cases...

@mgravell @philon-msft  thoughts there? Talking PhysicalConnection Reader/Writer status enums.

The failure tests need not retry loop n times.
Also:
- Removes the handshake queue, relying on the pipe directly instead.
- Formats TestBase for easier maintenance

This gets us going to queue commands while disconnected. We still need handoff to sibling connections but this gets us going.

We observe a race here between the connection state saying we're connected and the connection actually being selectable, this tightens that window tremendously.

This fixes the immediate issue but we need to be really sure we never queue anything awaited in the middle of nowhere into a backlog we never start. Now that I understand the issue, we can probably harden this a bit more.

Currently the way we handshake is to get everything configured, wait for a tracer to complete, and then issue the tiebreakers to all servers if they are in play. This complicates a few things with respect to timings, duplication, and write paths being a one-off for tie breakers, which I tripped on hard in #1912.

In this, we instead move the tie breaker fetch as part of AutoConfigure as a fire-and-forget-process-the-result-later setup with a dedicated processor. This all happens before the tracer fires moving us to the next connection phase (added comments) so we should be safe. It should reduce both complexity and overall connection times proportional to endpoint latency (since we wait for completion right now).

What needs adding here is tests with us disabling commands like INFO, GET, etc. and ensuring things still behave as we want. In the overall, the tie breaker is slightly less isolated but _should_ be happening in the same order and with the same exception if any - no net result change is intended there with respect to how we do or don't error along the way. But we never want a connection to fail _because of a tiebreaker_ and I think that warrants a few tests:

- [ ] Disable `INFO` and see if we can connect
- [ ] Disable `GET` and see if we can connect
- [ ] Store some invalid TieBreaker and see if we can connect (e.g. make it a hash instead of a string)
...and maybe others?

…/primary-async

If I'm going to die on the hill of a space in Stack Overflow, gotta get the others right...

Good suggestions from @philon-msft - see #1969 (comment)