client: cap RateLimitLinearJitterBackoff Retry-After waits at max

[official-burak]

Description

RateLimitLinearJitterBackoff returned a parsed Retry-After duration without applying max (RetryWaitMax). A 429 or 503 with Retry-After: 3600 (or a far-future HTTP-date) could stall the client for that whole interval even when the caller set a much smaller ceiling.

The exponential path in DefaultBackoff already treats max as a hard cap. This change does the same for the rate-limit helper: if Retry-After is larger than max, wait max instead. Values at or below max are unchanged.

DefaultBackoff is left alone; #247 / #283 cover that helper.

Related Issue

Fixes #295

How Has This Been Tested?

Fail-then-pass on TestBackoff_RateLimitLinearJitterBackoff:

• Before the code change, cases with Retry-After greater than max failed (expected 1s, got 2s and expected 3s, got 1h0m0s).
• After the cap, those cases pass. Existing in-range Retry-After cases still pass.

Also ran:

go test -count=1 -run TestBackoff_RateLimitLinearJitterBackoff .
ok

go test -count=1 -race .
ok

[hashicorp-cla-app]

All committers have signed the CLA.

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}