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