Easier granular control of retry interceptor without losing built-in `retry-after` handling

This Would Solve...

I want more granular and flexible control over retry behavior. For example, instead of retrying only with specific error codes, I want to bail out of retries with specific error codes. Similarly, instead of retrying with specific http status codes, I want to bail out with specific http status code ranges (e.g., statusCode > 400 && statusCode < 599 && statusCode !== 401 && statusCode !== 403 && statusCode !== 404 && statusCode !== 405), or bail out of retries with a specific header.

Currently, I can accomplish this with the retry callback in the retry option, but if I provide a retry callback, I will lose undici's built-in retry-after header handling (which is in RetryHandler[kRetryHandlerDefaultRetry]):

https://github.com/nodejs/undici/blob/1bc83eaee7d743f8c3b52df880f5596c335b9818/lib/handler/retry-handler.js#L41
https://github.com/nodejs/undici/blob/1bc83eaee7d743f8c3b52df880f5596c335b9818/lib/handler/retry-handler.js#L107

I want to have both custom retry bailouts and retain undici's built-in retry-after handling.

The Implementation Should Look Like...

A shouldRetry callback in the retry option should receive context (which contains state and opt), header, method, statusCode, and errorCode. The callback should return a boolean or a number to determine whether the retry should continue and how long it should wait before the next retry.

I Have Also Considered...

Exposing RetryHandler[kRetryHandlerDefaultRetry] as RetryHandler['onRetryAfter'], which can be then called inside the custom retry callback.

Start with lib/handler/retry-handler.js, especially RetryHandler[kRetryHandlerDefaultRetry] and the existing retry option handling linked in the issue. Trace how retry callbacks and retry-after headers are currently processed. Done means custom retry bailouts can be combined with built-in retry-after handling while honoring the proposed callback inputs and return values.