* really nasty commit - incomplete investigating thread-race

* fixed race - was incomplete messages (packet fragmentation)

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.