It appears we just never use this property anywhere and never noticed, but users did long ago. See #229 for details.

Also adds some testing around this. While this may be considered a breaking change, I'm really going to err on the side of this is a plain on bug fix on a rarely used property. This doesn't impact any existing tests.

This is a known failure - will try to address next week.

This could be a terrible idea, but I hope it helps isolate failures and increase stability a bit.

Multiple runs aren't safe here...new key filter is.

This is a race in the implementation due to pub/sub order and locking. Just improving the test to help illustrate it.

High delays before weren't fixing the test on a stressed server, they were allowing the interval-based reconfiguration to mask the failure.

Though we lock on servers here, serverSnapshot is iterated in more cases, this reconfiguration iteration leaves null entries in the array causing downstream issues.

This is tricky, because you can't write to it if there's no test, xUnit goes boom. We can't write to the ITestOutputHelper here without failing the suite depending on the race.

But still, want to avoid dumping to the console and build log directly.

The jitter was causing 01:00:00 vs 00:59:59.9999967 due to the time between calls under load, but when you simplify the math: it should always be zero no matter what.

Also adds a delay after for restoration.

More dupe runs issues.

This test failing hoses many that follow..

It occurs to me the basis of multi-testing the same keys are fundamneally problematic, hidden behind the Me() call - at least fix those in a batch here.

So this one is fun. Windows caches DNS, including a miss. The second test runner will fail synchronously in the Socket.BeginConnect() call due to the DNS looku failing immediately (no need to wait!). This beaks our assumptions of it failing asynchronously in these tests.

If this resolves the issue, we'll put a wrapper in the .BeginConnect() call to capture and recognize the SocketException "No such host is known" and return the RedisConnectionException users expect.

This is on the way to v2.0 and Mono support (see #842 and #845 for discussion).

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.

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