add infinite retryWithBackoff variant

[smaldini]

Currently using Integer.MAX_VALUE as numRetries argument doesn't work as it is decremented as any other num retries. We should support this and/or eventually add a a simple retryBackoff(Duration) argument.

[simonbasle]

Realistically, using Long.MAX_VALUE should be enough, unless I'm missing something. The fastest possible backoff delay will exhaust the Long.MAX_VALUE "infinite" retries in... roughly 292 million years! (see analysis below)

So I think we're good... 😜

The only combination that would differ from that is "infinite numRetries with ZERO backoff", but that boils down to retry().

Maybe that was what you had in mind @smaldini? Make retryBackoff(Long.MAX_VALUE, Duration.ZERO, Duration.ZERO, 0.0d) an alias for retry()?

Why 292 million years?

Currently the lowest resolution for `Mono.delay` (which drives the backoff) is at best 1ms, provided the OS can even match that precision. Any `Duration` under that precision will be rounded down to 0 MILLIS, so most schedulers will consider that a direct task execution.

(note the actual precision in retryBackoff has to be worse than that, since there is the overhead of resubscribing)

Even if the precision was down to the NANOSECOND, with a max backoff of 1 nanosecond and numRetries == Long.MAX_VALUE, it would still take 292 years for the backoff to reach the Retries exhausted state.

LONG_MAX nanos
 = 2562047 hours
 = 106751 days
~= 292 years

LONG_MAX millis
 = 2562047788015 hours
 = 106751991167 days
~= 292471208 years
 = 2924712 centuries
 = 292 million years

[simonbasle]

Note the function produced by retryBackoff does accept long numRetries (so Long.MAX_VALUE) and never decrements that number but rather compares the index()-produced iteration number with the constant numRetries.

[simonbasle]

Closing, this is good for now. When a combination of infinite retries and no backoff is needed, the way to go is to use .retry().