Was incorrectly failing when completing near-instantly with a local server.

The Streams data type is available in release 5.0 RC1 and above.

- Implemented Sync & Async methods for all Stream related commands (minus the blocking options) as of 5.0 RC1.
- Added tests for the synchronous versions of the Streams API but the testing is a work in progress. Need to refactor for reuse within the streams tests and write a more thorough suite of tests.
- Added a NameValueEntry struct which mimicks HashEntry. Using HashEntry for the name/value pairs of stream entries seemed wrong. Perhaps refactor the usage of HashEntry to the more generic NameValueEntry and deprecate HashEntry?

Being removed in v2.0

Useful for WSL testing Streams

I think there's a race in ReconfigureAsync with clusters here where the last subscription to finish is left out...but not seeing it yet. Tests show it over and over, though.

Trying to get this to register in VSTS...

This allows running VSTS builds in 1 step.

GitHub conflict editor hosed this. Blah.

Not sure why this is failing...we need more info. It could be socke exhaustion on the box.

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.