2.x: Completable class for valueless event composition.

[akarnokd]

I saw this mentioned in this talk from @benjchristensen

This PR adds a new class Completable which allows composing events
that never want to fire onNext, but only onError or onComplete. It
is built upon the same Reactive-Streams principles as Single,
NbpObservable and Observable.

I've added most methods that made sense and left out the others (such as
map and flatMap) that would require at least a single value.

Depending on whether this type is actually required, I'll add unit test to this PR or in a new PR in case this gets merged.

[akarnokd]

I'm adding unit tests and some fixes, stay tuned.

[akarnokd]

Added 240 unit tests and fixed a few bugs.

[akarnokd]

I've added amb, startWith and endWith methods + their unit tests. The latter two have convenience overload that help with continuation-style flows (run the Completable before or after the Observable/NbpObservable delivered its values).

[artem-zinnatullin]

@akarnokd do you really see much sense in a separate class for arrays?

You can provide an override where passed array will be wrapped into ArrayList and then passed to the CompletableOnSubscribeConcatIterable.

Less code — less bugs :)

[akarnokd]

Less allocation, more performant code.

[ibaca]

What is the difference between Completable vs Single<Void>? It's possible to add some utility methods to Single to terminate using null values, so end up almost with the same interface than Completable. Maybe is better to improve Single as something similar to a Deferred/Promise which will handle the 1/0 items situations (been 0 a null item) which is probably the origin of both interfaces. Even Completable might be just a Completable extends Future<Void>. So end up with Observable<T> (async multiple items) and Future<Void> (async single item) as main types (as puts here for some time http://reactivex.io/intro.html 😲).

Hope this helps. Just ignore me if you think that this is non sense. I see that @akarnokd are doing amazing things this days (specially rxjava v2), I'm not try to say that this pull request is bad or something similar.

[akarnokd]

The difference is that, among other things, you don't have to drag around a mute type parameter. Null values are forbidden with 2.x and Reactive-Streams anyway. Future void is not an option because Completable is a deferred cold computation which runs only if one subscribes to it whereas Future is hot and is expected to be running or already completed such as AsyncSubject.

[benjchristensen]

Consider making Completable implement both Publisher and IObservable (an interface for Observable similar to Publisher for Flowable) so that Completable can be composed directly with either a Flowable or Observable without special method overloads.

[akarnokd]

I've started out with Completable implements Publisher<Object> but it didn't work with Subscriber<T> because T is not a supertype of Object and java doesn't have a bottom type in its type system (its top type is Object, however, Void is not a bottom type so that Void extends every other type). The same would be true for IObservable. So what's left is a bunch of subscribe() method with call-site variance.

[benjchristensen]

Well that really sucks that Void doesn't work properly. How about as Publisher<?>?

[akarnokd]

You can't have wildcards as the type parameter of the super type.

[benjchristensen]

:( Oh well.

[NoahAndrews]

Is there any chance we will get this with RxJava 1.x?

[akarnokd]

The PR for 1.x has already been merged and should appear in 1.1.1

[stealthcode]

see #3444

[akarnokd]

Closing, will be included in the complete backport PR.