This is likely causing some fail as we're not sure everything has been sent. If we *can* be sure, it'd be safe to close it early, otherwise we need to eat the TIME_WAIT.

Buuuuuuut now that I think about it. Linger only works inherently *when there's data left to write*. If our data is *in the pipe* and not yet *in the socket buffer*, we'd be killing it early. This may explain several failures, especially inconsistent and under-load ones.

We really need to figure out how to best close the socket *when the pipe is done* in the Dispose() case. /cc @mgravell

add TEST tracers when connecting and closing; prefer PING on subscribers; avoid NRE in connect; set no-linger

Try to make sure that QUIT doesn't get stuck to one side with no chance of completion; do a better job of completing messages that we never send; stamp time of ambient exceptions

add the SocketConnection ShutdownKind/SocketError to the failure outputl make Roslynator happy in a bunch of places

find+fix more ways of not competing tasks; better tracing of message faults via new MessageFaulted event (requires `internal` access and a build flag); improve ManyContexts (test) stability

handle AggregateException it SafeStatus (transaction tests); be more aggressive about completing the queue in ChannelMessageQueue.Unsubscribe[Async]Impl

found more ways that things could fail to be completed (completion manager being null); use the awesome power of extension methods to fix that without a refactor

not having a bridge is no excuse not to complete something; if the bridge is unavailable, complete things on the shared manager (which will defer to the thread-pool if disposed)

code; the question is whether we guarantee that the completion has
*already run* or not - we don't want to do this on the processor, as
anything that involves changing Task status can lead to thread theft, so
it is done via the custom thread pool; the fix here is simply to check
that the task *becomes* cancelled (in a timely fashion), rather than that
the task *is* cancelled; anyone using "await" or ".Wait()" ".Result" will
observe that *anyway*; also tidied up some efficiency code to reduce exception
allocations in this scenario

This now throws early for an invalid call, rather than a currently confusing server message to users (see #724 fo details).

This is more consitent with our commands, enums, and redis docs themseleves.

fixed incorrect expectation for #900 - or... should it resolve at parse time? (decisions, decisions)