Add support for reactive Resilience4jBulkheadProvider to provide bulkhead support for reactive operations (Mono and Flux).

[yavor300]

Add support for reactive Resilience4jBulkheadProvider

• Introduced ReactiveResilience4jBulkheadProvider to provide bulkhead support for reactive operations (Mono and Flux).
• The provider decorates reactive streams (Mono and Flux) with a SemaphoreBulkhead to enforce concurrency limits.
• Integrated ReactiveResilience4jBulkheadProvider into the run methods for Mono and Flux to handle bulkhead constraints, along with optional CircuitBreaker and TimeLimiter configurations.
• Usage in the run methods:
  • For Mono<T>:
    1. The bulkheadProvider.decorateMono method decorates the Mono with bulkhead protection.
    2. The decorated Mono is then transformed with CircuitBreaker logic (CircuitBreakerOperator).
    3. If a TimeLimiter is configured, a timeout is applied, and any timeout error is reported to the CircuitBreaker.
    4. A fallback is applied to handle errors gracefully.
  • For Flux<T>:
    1. Similar decoration and transformations are applied for bulkhead, CircuitBreaker, and TimeLimiter.
    2. Fallback logic ensures graceful degradation for errors.
• Ensured that only SemaphoreBulkhead is used for reactive scenarios since FixedThreadPoolBulkhead is not supported.
• Updated configuration and tests to validate the behavior and integration of the provider in reactive streams.

This MR addresses issues #166 and #105 by introducing ReactiveResilience4jBulkheadProvider for handling bulkhead constraints in reactive streams.
Refs #166, #105

[yavor300]

Closes #166, #105

[ryanjbaxter]

Thanks! This is great!

If you would like we could merge this into our next minor release but we would have to rework the PR a bit to remove any kind of breaking changes to the APIs (changes to public method signatures).

If not we can wait till the next major to merge it (which would be in a few months).

Either way it would be nice to add some documentation about the reactive support.

[yavor300]

Thanks for the feedback!

I prefer to merge this into your next minor release.

I have reworked the PR by adding additional constructors instead of changing the existing public method signatures.

The only place a public method signature (bean declaration) is changed is inside the ReactiveResilience4JAutoConfiguration class but this is done because we need to inject the ReactiveResilience4jBulkheadProvider bean into the ReactiveResilience4JCircuitBreakerFactory.

Should I create a separate bean method that includes the ReactiveResilience4jBulkheadProvider and mark the current one as @Primary?

Also, I agree to document that change.

[ryanjbaxter]

No for the configuration class you can change that public method. Just mark the old constructors as @Deprecated

[yavor300]

I annotated the old constructors with @Deprecated and extended the bulkhead-pattern-supporting documentation with an explanation of the newly added provider.

[yavor300]

Just for clarification, when are you planning your next minor release?

[spencergibb]

Watch here for updates. We're doing some planning very soon and will add a date there.

[ryanjbaxter]

After discussing scheduling with the team, the next minor will be in the June timeframe. You can keep an eye on our milestone dates for the most up to date information. That said we will likely merge this before the end of the month once we have a branch.