We're stable enough to not need this anymore, yay for faster runs!

As we go for green on the test suite, we'll want this checked in PRs and such. And in general DEBUG and RELEASE not matching is becoming a pain. Trying to minimize the differences.

This moves the socket bits all the physical connection which I think is a lot easier to grok than the double relationship between it and SocketManager. Pushing a PR for sanity check.

This is pretty much a boolean now...let's make it one. Also note PhysicalConnection is passes as `this`, it can't be null.

This helps for real-time output on long-running or hanging tests.

make sure there is only **one** path that can cause endpoints to be added, and ensure that the activation happens after the constructor - removes race condition that can lead to abandoned endpoints; note as part of this, switch the server-snapshot to span-based

This fixes net462, but not netcoreapp test hangs

Marc's working on connection code so we'll plug these in after.

This simplifies internal logistics and our profiling a bit

Fix #838 - provide mechanism for app-code to compute hash-slot using the muxer's state; also avoid hash-slot overhead when not cluster

fix #880 - missing zrevrangebylex; note that to avoid confusion this automatically adjusts to inverted parameter min/max usage, just like zrangebyscore already does

key bugs resolved:

- make sure that we only push things into _writtenAwaitingResponse until we have actually written them; they are allowed to throw certain errors *before* write, which breaks the queue completely
- ensire that MOVED redirects are sents as "internal call"; this means that if this is a new server, it can be queued rather than dropped
- allow MOVED code to select a server that isn't "up" yet

additional tweaks:

- change accessibility on WriteImpl to ensure everything goes via WriteTo
- renamed some methods to clarify what the lock status is: ...InsideWriteLock, ...TakingWriteLock, etc
- fix bug where ExportConfiguration can fail if a result is nil (although this might be a false outcome)
- why did StringGetWithExpiryMessage specify NoRedirect?
- clarify messages for ProtocolFailure and MOVED