Incrementing retries should possibly not pass `Response`

suggestion: response is always None at this point, and passing it is the risky part of the plumbing.

It's reset to None at the top of each loop iteration and only assigned on the success path, so the except branch can only ever pass response=None — _should_retry then falls through to response = e.response anyway. That makes the parameter dead.

It's also a duck-typing trap: Retry.increment and retries.sleep expect a urllib3.response.HTTPResponse and call get_redirect_location(), .status, and (on urllib3 1.26, permitted by the new floor) .getheader("Retry-After"). A requests.Response has none of those. Today the truthiness guards short-circuit because all three members of _RETRY_REQUEST_EXCEPTIONS are raised without a response attached — but any future change that surfaces a retryable RequestException carrying one turns a would-be retry into AttributeError, escaping the except MaxRetryError handler as an unrelated error type.

Passing response=None explicitly (the retry decision is already driven entirely by exception type) removes both the dead parameter and the trap.

Originally posted by @rtibblesbot in https://github.com/learningequality/morango/pull/348#discussion_r3669168541

Start by locating the retry loop and its _should_retry call, then read how Retry.increment and retries.sleep handle their response argument. Ensure the exception path passes None without exposing a requests.Response, and run the existing retry-related tests to confirm retryable exceptions still retry without AttributeError.