Note unlike #3803 , this is not a regression as the pre-requests code didn't do this.

Note that requests has native max_retries logic which we can use.
It requires working at the requests session & adapter level.

I've also looked for a sane requests wrapper which provides simplified retry, and oddly not found one.

Note, if there is a retry, then surely there needs to be a new status code check somewhere, but this doesnt appear to be documented anywhere in requests; see #3805 (comment).

It looks like requests now supports max_retries everywhere, so this should be fairly simple.

Optional: if a transient error occurred, such as 500+, the bear should be disabled with a warning.

However this could complexity can be deferred to be added later in #3332

I would like to be assigned this issue

What value of max_retries is expected? Also what should be an optimal backoff_factor value for the retries?
Also what is to be done if error code persists after max_retries?

If max_retries is hit and the error code persists, a RetryError is raised which is causing the pytest to fail. How do I handle the pytest failing?

How about handling the RetryError by attempting to download once more(in the except statement) so that HTTPError can be raised with the latest status code

Please review the PR and suggest changes