Introduce abstractions over Reactor API

[JonathanGiles]

We might consider abstracting away Mono / Flux types with our own types. The premise of this being that if we control an abstraction, we might be able to shelter users from breaking changes in the Reactor APIs. We could conceivably even change implementations of our async implementation without impacting the user.

The downside of this is obviously the amount of work required to build our own APIs, and to ensure that these APIs can work over multiple implementations (e.g. Reactor3, Reactor4, RxJava (as a proof of concept more than anything), CompletableFuture, Virtual Threads, etc).

If we did consider investigating this further, we could extend this investigation by looking into removing reactor from azure-core, and to introduce a pluggable mechanism in much the same way as we do HTTP clients, etc today.

[stliu]

FYI https://smallrye.io/smallrye-mutiny/

[github-actions]

Hi @JonathanGiles, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.