feat(async): add jitter to retry exponential backoff

[lionel-rowe]

Fixes #3378

[lino-levan]

I'm pretty strongly -1 against complicating the API to allow for arbitrary backoff functions. When I made the PR to introduce async/retry, I made a conscious decision to not do that (because outside of exponential backoff, what algorithm would you need?). I chose not to add jitter at the time because I didn't understand what the use case was but I think you did a good job in #3378 explaining why it might be useful.

TLDR; I think adding an option for jitter would be fine, but please don't overcomplicate the API with backoff functions.

[lino-levan]

I never thought about making jitter enabled by default but honestly that makes sense (plus it removes an option which is always nice). Thoughts @iuioiua?

[lionel-rowe]

I never thought about making jitter enabled by default but honestly that makes sense (plus it removes an option which is always nice). Thoughts @iuioiua?

Ah I thought that was what you meant, but re-reading your post I see I misunderstood.

Pros of always using jitter:

1. Likely to significantly decrease number of failed API calls (especially those due to 429 Too Many Requests) in real-world scenarios
2. Likely to significantly decrease time-to-completion in real-world scenarios, mainly as a result of 1, but also because the average time between calls is spaced closer together
3. API remains completely unchanged

Pros of having an option for jitter, disabled by default:

1. Default behavior remains completely unchanged
2. More deterministic... sort of? I'm not sure whether an unknown power of m between x and y is meaningfully more deterministic than a completely random number between x and y here. Is there any reason a consumer would specifically want the number of seconds between each retry to be a power of 2?

Pros of having an option for jitter, enabled by default:

1. Gives the most-likely preferred behavior as default but allows opt-in to the old behavior

[kt3k]

LGTM. Nice!