Revert of cache/replay

[abersnaze]

#3076. I did revert commit of the PR that added back pressure support to the cache operator and ran a canary. Our production systems seem stable now even with the new merge.

[davidmoten]

That's good news. Not sure what time @akarnokd has for reviewing .cache backpressure work. If we can't fix this short term would be nice too see a fix for #3026 go in 1.0.13 if backpressure doesn't make it. Quick summary is in 1.0.12 .cache emits nothing until source has completed.

[akarnokd]

Can you create an unit test based on the usage pattern? It would be also interesting to verify replay().autoConnect() since it ought to be functionally equivalent to cache().

[abersnaze]

I have no clue at the moment what the actual code path is causing the lockup. It'll take awhile for me to instrument code to narrow which usage pattern is causing the problem.

[benjchristensen]

I believe the issue we're seeing comes from use of cache() in Hystrix: https://github.com/Netflix/Hystrix/blob/990394e98ba7472b96d90d7246e785d0966ade9a/hystrix-core/src/main/java/com/netflix/hystrix/AbstractCommand.java#L481

We use Hystrix at very high volume, and cache() will be used by a large percentage of those calls. This explains why this impacted our canary so significantly.

[abersnaze]

I've reverted both the cache and revert related commits. The tests and the canary seem to do fine so far.