Is your feature request related to a specific problem? Or an existing feature?

Related to #506.

Imagine a worker service pulling messages from a queue (e.g. Azure Service Bus) and issuing circuit-breaker protected calls to downstream HTTP endpoints. If the downstream services go down and the circuit breaks, the worker has no easy way to know when the circuit breaker would possibly become closed again.

#506 recommends applications to stop processing messages for some time, and I would agree. The problem is "for how long". Knowing when the circuit breaker is likely still open without relying on actually performing and failing the request is important for message queue scenarios, because excessive retries and failures can quickly exhaust message delivery limit and deadletter the messages unnecessarily.

Applications can surely take a guess, but it still needs this piece of information to make an informed decision on how long to cease message processing. It wouldn't help if the circuit breaker is configured to break for 2 days and the application blindly guesses 2 hours.

Describe the solution you'd like

Indicate the time when the circuit breaker can possibly become closed again in BrokenCircuitException. Possible API:

  public class BrokenCircuitException : ExecutionRejectedException
  {
+     public TimeSpan? RetryAfter { get; }
  }

This matches RetryAfter from RateLimiterRejectedException. Pulling it up to ExecutionRejectedException is not advisable because it does not apply to all derived exception types.

For IsolatedCircuitException, set this to null.

Additional context

No response