Upgrade to rxjava 3.x

[ray-roestenburg-da]

Upgrade to latest rxjava 3.x.

The 2.x version is end-of-life as of February 28, 2021. No further development, support, maintenance, PRs and updates will happen. The Javadoc of the very last version, 2.2.21, will remain accessible.

See https://github.com/ReactiveX/RxJava

Depends on

• [ ] deprecate all references to deprecated ledger API features, and all symbols that depend on those
• [x] #15424
• [ ] #15425

[stefanobaghino-da]

A viable approach, as suggested initially by you off-band with a few points from me:

• keep maintaining an RxJava2 library for the time being (bindings-rxjava)
• create a new library, bindings-rxjava3 which uses RxJava3
• minimize the changes on our library to reduce the migration complexity for customers
• document the migration path as part of the library's documentation, including a pointer to RxJava3's own migration guide
• migrate all the examples in our documentation and templates in the SDK to the new library
• work together with CX to identify a candidate project for porting so that we can identify issues
• iron out migration path wrinkles identified at the step above
• when all the above is clear, deprecate bindings-rxjava following our usual backward compatibility policy

[S11001001]

We should exclude any parts of bindings-rxjava that are currently deprecated from bindings-rxjava3 at the time of this copy.

[S11001001]

I've come around to @stefanobaghino-da 's idea that we ought to clean up the overloads with builders or other argument-set representations before doing the rxjava3 split, and then delete the old deprecated functions in rxjava3 so we have a clean base.

[stefanobaghino-da]

I've come around to @stefanobaghino-da 's idea that we ought to clean up the overloads with builders or other argument-set representations before doing the rxjava3 split, and then delete the old deprecated functions in rxjava3 so we have a clean base.

Any specific reason why you'd favor my take?

[S11001001]

@stefanobaghino-da So that we have a good stepped approach to simply not having the deprecated functions in rxjava3.

[stefanobaghino-da]

@stefanobaghino-da So that we have a good stepped approach to simply not having the deprecated functions in rxjava3.

Makes sense. I think it's cleaner to start with a library free of deprecations, as long as we can have a migration path.

[stefanobaghino-da]

I would also recommend evaluating whether something can be done for the overloads with a security token. I think a gRPC interceptor might be part of the solution.

[ray-roestenburg-da]

Sounds good