feat(rest): support AWS SigV4 request signing for the REST catalog

[plusplusjiajia]

What

Adds AWS SigV4 request signing to the REST catalog client, for catalogs that authenticate REST requests with SigV4.

Approach

• SigV4Signer + a small HttpRequestSigner trait; the client signs each request after token + header.* extras. Follows Iceberg Java's RESTSigV4AuthSession (signs all headers minus a blacklist).
• PayloadHashMode handles the Iceberg detail: x-amz-content-sha256 is base64 for non-empty bodies (hex for empty); StandardAws keeps hex everywhere.
• Config: rest.sigv4-enabled, rest.signing-region/-name/-access-key-id/-secret-access-key/-session-token (falls back to AWS_* env), mutually

[dannycjones]

There's a PR open for SigV4 signing, is this picking up from that one? #2311

I ask as its had a few rounds of feedback already.

[plusplusjiajia]

There's a PR open for SigV4 signing, is this picking up from that one? #2311

I ask as its had a few rounds of feedback already.

@dannycjones Thanks for the pointer — I'd missed #2311, just took a look and compared the two. Mine isn't based on it: it follows Iceberg Java's RESTSigV4AuthSessionRESTSigV4AuthSession(apache/iceberg#11995) and the merged iceberg-cpp version(apache/iceberg-cpp#616). The main difference I see is the base64-encoded x-amz-content-sha256 convention (the Java behavior), which #2311's hex-only signing doesn't cover and which some REST servers require.
I'm keen to help get SigV4 support landed either way. Since #2311 is further along, I'm happy to fold the base64 support into it rather than duplicate — or carry this one forward if you'd prefer. Whatever helps move it forward.

[CTTY]

I haven't thought quite clearly about this part yet, my general intuition is that it would be better to start from something like a AuthManager so we have a clean interface before diving into the specific implementation.

Would be happy to hear more thoughts on this