RetryStrategy: support retrying on HTTP status codes (429, 5xx)

[dokson]

Is your feature request related to a problem? Please describe.
RetryStrategy retries only on RequestException. A response with a retryable status (429, 5xx) completes the round-trip and is returned as-is — never retried. That's the main case people actually want retried, and urllib3/requests already cover it via Retry(status_forcelist=...).

Describe the solution you'd like
Add an opt-in field, empty by default (no behavior change):

@dataclass
class RetryStrategy:
    ...
    status_forcelist: tuple[int, ...] = ()

When resp.status_code in status_forcelist, retry under the same count/delay/backoff. Honouring Retry-After would be a natural follow-up.

Describe alternatives you've considered
Per-call retry wrappers downstream — duplicated everywhere and ignore Retry-After.

[lexiforest]

Isn't this covered by raise_for_status? If not so, it should be fixed there.

[dokson]

@lexiforest

raise_for_status already triggers retries today, since HTTPError is a RequestException and the loop catches it. The problem is it fires on every non-2xx/3xx, so it burns retries on permanent failures like 404/401/403.

status_forcelist follows the urllib3/requests model: retry only the transient codes you opt into (429, 5xx) while returning other responses normally. It also lets the 429 path honour Retry-After, which raise-and-retry can't.

To sum up:

• raise_for_status is about how to signal an error
• status_forcelist is about which codes to retry.

They're orthogonal.

[lexiforest]

What about raise_for_status(codes: Optional[list] = None)?

[dokson]

@lexiforest that's a different axis: raise_for_status(codes=...) decides which codes to raise, status_forcelist decides which codes to retry. The retry path also returns the final response on exhaustion and honours Retry-After, which the raise-then-catch path can't.