[FEATURE REQ] Add the ability to customize the scheduler used for timeouts/delays instead of creating a Schedulers.parallel by default on the blob storage client

[fcofdez]

Is your feature request related to a problem? Please describe.
Currently in all the code handling timeouts/delayed subscriptions (at least on the storage project see [1], [2]) use by default the Schedulers.parallel() which might be convenient in some cases but it doesn't allow a fine grained control of the resources used by the client.

Describe the solution you'd like
I would like to be able to inject a ScheduledExecutorService to be used in those cases, avoiding any unintended thread pool creation.

Describe alternatives you've considered
I was able to circumvent this limitation partially (i.e. creating a custom HttpPipeline that uses a custom request retry policy),
but in other parts of the client it's impossible to inject a custom Scheduler

Additional context
It seems like in other parts of the SDK this was possible at some point, see #5466

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• Description Added
• Expected solution specified

[fcofdez]

I've just noticed that reactor Schedulers allows to inject a custom factory, but in any case that's an implementation detail that should be hidden from the users.

[rickle-msft]

@JonathanGiles Do you have thoughts on how we should expose this to the public API surface?

[JonathanGiles]

Thanks for the feature request @fcofdez. I'll give some thought on how we could expose this. One option we have is to make this a configuration option present in our ClientOptions type. That would mean that we would apply this to all clients that are given this ClientOptions instance in their builder (and we are still in the process of introducing ClientOptions to all builders).

[github-actions]

Hi @fcofdez, 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.