Significant restructuring of subscriptions

[akarnokd]

I've re-abstracted the subscriptions to be more uniform and maintenance friendly.

• Enhanced BooleanSubscription to support inheritance and single unsubscription action through onUnsubscribe (Issue BooleanSubscription should be properly wired up to allow inheritance #591).
• Added BooleanSubscription.withAction to allow wrapping a single-time unsubscription action.
• Created AbstractAtomicSubscription which manages the lock-free manipulations through callbacks.
• Rewritted MultipleAssignmentSubscription to have two extension points in its logic, which allows simpler subclass implementations of SerialSubscription and SingleAssignmentSubscription. MultipleAssignmentSubscription does not extend AbstractAtomicSubscription because it has a much simpler state-transition logic whereas the AbstractAtomicSubscription with its callbacks would be an overkill.
• Rewritten CompositeSubscription and RefCountSubscription to use AbstractAtomicSubscription.
• Modified SafeObservableSubscription to use SingleAssignmentSubscription instead of duplicating its behavior.
• Extended Subscriptions with an unsubscribeAll method to capture the exception collection behavior when unsubscribing from multiple subscriptions.
• Added empty0(), empty1() and empty2() convenience methods to Actions. Haven't checked if such no-op ActionX instances are created manually somewhere.
• BONUS: ValuedCompositeSubscription<T> class where a value can be associated with a Subscription key.

[cloudbees-pull-request-builder]

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

[cloudbees-pull-request-builder]

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

[benjchristensen]

@headinthebox does this match what you were hoping for regarding Subscriptions?

[benjchristensen]

Is a SerialSubscription really a MultipleAssignmentSubscription in the inheritance manner? I don't think they are as their functionality is different and thus it doesn't seem to pass the "is a" test.

[akarnokd]

The SerialSubscription differs from MultipleAssignmentSubscription by a single operation: once the reference is swapped, the old is unsubscribed in SerialSubscription but not in the other.

[headinthebox]

I'd like to entertain the idea of inheritance a bit, since maybe it will put more structure in the mess of subscriptions.

Subscription

// adds isUnsubscribed
BooleanSubscription extends Subscription

// adds setSubscription(...) throws if sets twice (like "val")
SingleAssignmentSubscription extends BooleanSubscription

// allows to setSubscription twice, leaves previous unchanged (like "var")
MultipleAssignmentSubscription extends SingleAssignmentSubscription

// allows to setSubscription twice, unsubscribes old one.
SerialSubscription extends MultipleAssignmentSubscription previous

// adds add/remove(...)
CompositeSubscription extends BooleanSubscription implements List

It is always safe to pass a DerivedSubscription where you expect a BaseSubscription (unless you want swapping a subscription to throw, but I would say that is more a promise from the caller that they will never set the subscription more than once).

On the other hand, perhaps this is over-design.