feat(network): use Retry-After header for HTTP 429 responses

[arlosi]

What does this PR try to resolve?

Cargo registries that return HTTP 429 when the service is overloaded expect the client to retry the request automatically after a delay. Cargo currently does not retry for HTTP 429.

What changed?

• Adds HTTP 429 (too many requests) as a spurious HTTP error to enable retries.
• Parse the Retry-After HTTP header to determine how long to wait before a retry.

In this implementation, the maximum delay is limited to Cargo's existing limit of 10 seconds. We could consider increasing that limit for this case, since the server is explicitly requesting the delay.

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[weihanglo]

cc #13530, which I believe this partially resolves it.

[weihanglo]

I feel like we are on the way of dropping time? #15293

[arlosi]

cc #13530, which I believe this partially resolves it.

This only applies for things that use Retry. IIRC the publishing logic doesn't have built-in retries at all.

[ehuss]

Would it be possible to add a test using our HttpServer to ensure that this works going through curl? I imagine it would be something like adding a custom_responders?