Fixed deadlock in Subjects + OperatorCache.

[akarnokd]

Fix for Issue #971.

• I had to rewrite OperatorCache to allow testing for deadlocks in all Subject types.
• The terminationLatch was unnecessarily waiting for existing subscribers to deliver their termination events, which caused deadlock with repeat().
• Treating subjects as internal implementations was not necessary to fix the problem.

[cloudbees-pull-request-builder]

RxJava-pull-requests #912 SUCCESS
This pull request looks good

[benjchristensen]

I don't understand these changes yet, but on first review they are very awkward as the SubjectSubscriptionManager methods now both invoke a function and return a collection.

[akarnokd]

True, the rewritten Subjects don't require an Action1, they are fine with Action0. The changes had to be made since the CountDonwLatch logic acted as a synchronization block and emitting events while holding locks is prone to deadlocks, as the associated issue demonstrates.

[benjchristensen]

Ah, holding the lock is the issue. We should find a way of doing that without the latches at all, as it is blocking.

[akarnokd]

The latch has its use because once the state has been swapped to terminal state, we still need to perform some tasks on any related state within the particular subject before client notifications can resume: usually, it is to set the last event which then will be available to newcomers.

[benjchristensen]

I haven't merged this yet as I need to spend time better understanding this and the impact on design.

[benjchristensen]

Since this has conflicts and I did some cleanup based on our discussion above, I've opened #1040 for merging this.