Subscriber cleanup

[NiteshKant]

Problem

Publishers was using different implementations of CancellableSubscriber to provide different callbacks using inheritance. eg: by providing methods like doOnNext, doOnCancel, etc.

This is problematic as it requires calls to super.do* by implementator. Also, it created unnecessary class hierarchy with little benefit.

(Edit: Adding more context from the comments below)

There were 3 classes CancellableSubscriber, SafeCancellableSubscriber and SafeCancellableSubscriberProxy, each of them would override some of the methods from Subscriber. eg: doOnCancel was something that was to be used by SafeCancellableSubscriber and CancellableSubscriber in a way that SafeCancellableSubscriber had to implement doOnCancel and provide yet another method doOnCancel0 which if implemented by SafeCancellableSubscriberProxy will have to provide yet another protected method.
So, I figured not only the approach was error prone it was painful to code and maintain. Thus this approach where in specific callbacks can be overridden and controlled by the caller.

Modification

Rolled up all implementations into a single class that takes various callbacks as different lambdas.
This is easier to use and there are less chances of errors when the implementor forgot to call super methods.

Thanks @yschimke for the comment in PR #127 which led me to change the approach.

[yschimke]

I'm not sure my comment meant that changing to a deep Java 8 approach was the only solution, I suspect that more private methods and choosing which public doXXX to override was possible.

But I'm interested at the same time to see how this plays out. LGTM

[NiteshKant]

@yschimke Indeed your comment didn't suggest this approach but made me realize the problem with the older approach. Here was the problem with the older approach:

There were 3 classes CancellableSubscriber, SafeCancellableSubscriber and SafeCancellableSubscriberProxy, each of them would override some of the methods from Subscriber. eg: doOnCancel was something that was to be used by SafeCancellableSubscriber and CancellableSubscriber in a way that SafeCancellableSubscriber had to implement doOnCancel and provide yet another method doOnCancel0 which if implemented by SafeCancellableSubscriberProxy will have to provide yet another protected method.
So, I figured not only the approach was error prone it was painful to code and maintain. Thus this approach where in specific callbacks can be overridden and controlled by the caller.

[stevegury]

I had the same knee-jerk reaction than @yschimke but your comment motivate the current implementation.
Could you update the description of the PR so that the commit message contains the information?

Otherwise, 👍

[NiteshKant]

@stevegury updated the PR description