Add retry mechanism with backoff

[nbraun-amazon]

• Add the Backoff abstract base class with four backoff strategies
  based on https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/
• Add the Retry class which is constructed from
  a backoff strategy and a maximum number of retries, through the retry parameter

[adamserafini]

My 2 cents: obviously interested to hear what the core maintainers think, but I don't think this belongs in redis-py library. IMO this breaks the 'do one thing and one thing well' principal.

I would rather see 'back-off and retry' as a standalone library I can use for any network call instead of repeatedly bundling it with redis-py and any other library that might need to retry.

For example, here is an example of a standalone library covering this exact same functionality which I can already use with redis-py (or anything else) if I choose to do so: https://pypi.org/project/retry/

I have no particular say on the matter (this is just a drive by comment) but I would vote to close this PR without merging it.

[nbraun-amazon]

Thanks for your comment. This is a small change, and it has a specific API with callbacks on failures as well, which the library you mentioned does not support, as far as I can tell. Moreover, I don't think the retry with backoff mechanisms warrants adding an external dependency to redis-py.

[adamserafini]

Just to clarify, I don’t suggest to add external dependency to redis-py for retry functionality.

I am suggesting that ‘retry’ is a concern that can remain outside of this library, we do not need to build it into redis-py.

[abrookins]

Not a maintainer, but I like this PR. This allows a uniform retry policy that applies to all command executions, without requiring someone to figure out how to hook in an external retry library. Moreover, this allows configuring full jitter backoff. From my view, this PR makes redis-py more reliable for more people.

[nbraun-amazon]

Ping on this PR @andymccurdy. Please let me know your feedback. Thanks!

[chayim]

First @nbraun-amazon I love the approach - it's elegant and easy to understand. Things are tidy, nicely documented, and high quality. It also solves my personal, #1 issue.

I'm torn. I really love do one thing and do it well. It's the reason I love Unix. At the same time, it seems like python libraries in general as they mature move from that model to an extended version of it. I'd vote for inclusion. If anything, toggling retry to default False and friends, solve these concerns. I'm 👍 @andymccurdy ?

[chayim]

Can we change the comment format to docstrings for classes and functions when not please (i.e EqualJitteBackoff, DecorrelatedJitterBackoff..) Similarly, can we docstring functions like reset and compute.

Overall, I'm a proponent of merging - but I'd like to hear from @andymccurdy

[nbraun-amazon]

Can we change the comment format to docstrings for classes and functions when not please (i.e EqualJitteBackoff, DecorrelatedJitterBackoff..) Similarly, can we docstring functions like reset and compute.

Overall, I'm a proponent of merging - but I'd like to hear from @andymccurdy

I addressed your comments. Thanks for your feedback.

[abrookins]

I'm in favor of merging this PR. It creates a more reliable, batteries-included client out of the box, which I like. It does "one thing," being Redis connection and command management, better than before, IMO.

Changes implemented.