feat(rest): add sigv4 retry configuration defaults

[mrutunjay-kinagi]

Rationale for this change

When REST catalog uses SigV4 signing, retries were not configured on the mounted adapter. This change adds explicit retry defaults for signed REST requests and makes retry count configurable.

Changes:

• Added rest.sigv4.max-retries catalog property.
• Default retries set to 10 attempts.
• Retries configured for idempotent methods (GET, HEAD, OPTIONS) and common throttling/transient codes (429, 500, 502, 503, 504).

Are these changes tested?

Yes.

• Added test_sigv4_adapter_default_retry_config.
• Added test_sigv4_adapter_override_retry_config.
• Verified with targeted pytest run.

Are there any user-facing changes?

Yes.

• New optional REST catalog property: rest.sigv4.max-retries.
• Improved resilience for throttling/transient HTTP failures on SigV4-enabled REST catalogs.

[Fokko]

Seems reasonable, thanks @mrutunjay-kinagi for working on this 🙌

[mrutunjay-kinagi]

Seems reasonable, thanks @mrutunjay-kinagi for working on this 🙌

@Fokko Thank you 🚀

[mrutunjay-kinagi]

@kevinjqliu @Fokko Thank you 🚀

[mparry]

@Fokko / @kevinjqliu

I understand the preference for simplicity here, but it seems that this current implementation leaves all urllib3.Retry settings as default besides the total number of retry attempts. In particular, that has the default behaviour of applying no back-off whatsoever:

https://github.com/urllib3/urllib3/blob/2.6.3/src/urllib3/util/retry.py#L158

In the case of the endpoint returning responses such as 429 where the appropriate action is to reduce the rate of requests, isn't this potentially going to increase the rate of requests and thereby make matters worse?

(Happy to open a separate issue and potentially even PR for this, but this seemed like the most appropriate place to comment initially.)