Merge many fixes

Contains the PR #1893 and a possible fix for the premature RxRingBuffer unsubscription and NPE.
> Btw, why are these queues pooled in the first place?

Which perf comments are you referring to?

Inside `RxRingBuffer` it is the `createUseAndDestroy1` tests that drove pooling. This is a very common use case in request/response systems. It was a 10x difference I believe. Netflix production code taking canary traffic died when I tried running this code without pooling due to object allocation and garbage collection overhead. 

That does not mean however that it is the right solution, as the pooling causes lots of grief. If we move away from pooling though we need a solution that does not kill the system with object allocation overhead. That means we won't be able to use ring buffers (which pre-allocate up front) even if we never use it. Linked lists are also problematic as they allocate a node per item, but the benefit for them is they only allocate when we need the buffer (under backpressure cases). 

I'll spend more time thinking on this as well, but please continue trying to help on this. I need someone to work together on it as it's a rather non-trivial problem to balance the various competing needs. The issue that drove to this was primarily massive object allocation overhead that killed throughput. I spent days with Java Mission Control profiling various options to get to the current design ... but obviously left behind concurrency bugs.