Let's see if this is a race...I'm still unable to run locally, though.

A demo of how much this saves in complexity.

This was an expedition, but here's the history:
- There are 2 forks in the connection logic
 - One for Mono (the DnsEndpoint split, see #20 and #155)
 - One for .BeginConnect() and one for ConnectAsync (because netstandard1.x was "async all the things!")
- There's a behind-the-scenes fork on completion type, but for actual library consumers (and not tests), it was always .Any, which was effectively .Sync.

There was also a critical bug fix in #113 that unfortuantely added a lot of complexity here. The maintenance problem is this complexity wasn't even used, as far as I can tell. It was only ever exposed to even be possibly used in the test project. So we had complicated connection logic, only for the sake of testing it. Unless I'm an idiot, which is entirely possible.

This commit removes that logic and simplifies things, as a first step that's a unit in itself. It does not fix Mono. There are other issues there, but thanks to WSL I can readily run the test suite under Mono on Linux now. Mono has a littany of other issues which I'll comment on in #314.

The most important thing here is that we don't regress what was fixed in #113, as this doesn't readily show in tests.

In unit tests mocking out an IDatabase with implementations that throw
an error was not possible. Constructing the Exception instances wasn't
accessible in user code. It is now.

A lot of connections are ridiculously slow even to localhost at least in testing...let's timestamp the output (including milliseconds) so we can see what's happening.

This is working as-design as ITransaction : IBatch and it's not safe in either, but adding a test to ensure it's performing correctly.

The article is about minIoThreads, but example use maxIoThreads

Fix indentation level on a nested list.

Don't log details in Exception thrown by PhysicalConnection unless `IncludeDetailInExceptions` is true. (#827)

fixes 822

The documentation for the overload of IDatabase(Async).HashSet(Async)
that takes multiple fields/values was somewhat ambiguous. It could have
been read to mean that fields not set as a part of the HashSetAsync are
deleted rather than preserved. The documentation for HMSET was clearer,
so this borrows some of the verbiage from the Redis documentation into
the documentation for HashSetAsync.

This takes out the global build if it throws...let's not do that.

These were broght over from Booksleeve long ago and were duped.

Turns out redis on Windows is hella flaky here - the test runs fine against *nix hosts - disabling for now.

Fixes test runs for 2.0 and the UWP error.

Branching for repro purposes...this breaks all tests runs due to UWP shenanigans.

Example of setting ```minIoThreads``` configuration option for ASP.NET was not shown correctly.

There was a race here under load with the last set and the first key scan...let's not do that.

This was breaking integration tests but affects all zero-latency server situations. There's a good description in code, but the basics are a race between a broadcast (which goes first) and the post-SLAVEOF reconfig (which loses) creates a situation where the proper topology isn't seen until the next reconfig time span pass.

We now prevent that broadcast (we're broadcasting to ourselves) from running on ourselves because we're about to run another one anyway. This doesn't 100% eliminate the race because there's a minute chance of a pub/sub landing between the 2 if blocks here in an external Interlock. But the chance is crazy small now, at least.

Note: the logging of *why* a reconfig didn't run is now enhanced as well. We log what was trying to run and what was blocking it in the output for much easier debugging next time.