Add a builder for signing HTTP request

[ysaito1001]

Motivation and Context

#3388 (comment)

Description

This PR attempts to provide more ergonomic API for request signing. As documented in aws_sigv4, customers need to follow these steps after creating an Identity and a SigningParams:

// Convert the HTTP request into a signable request
let signable_request = SignableRequest::new(
    "GET",
    "https://some-endpoint.some-region.amazonaws.com",
    std::iter::empty(),
    SignableBody::Bytes(&[])
).expect("signable request");

let mut my_req = http::Request::new("...");
// Sign and then apply the signature to the request
let (signing_instructions, _signature) = sign(signable_request, &signing_params)?.into_parts();
signing_instructions.apply_to_request_http1x(&mut my_req);

This PR allows them to call SignWith::sign_with trait method with SigningPackage instead:

let signing_package = SigningPackage::builder()
    .signing_params(&signing_params)
    .build()
    .expect("required fields have been set");
my_req.sign_with(&signing_package);

Testing

Relied on existing tests in CI

A semver failure in CI can be ignored; A public API SigV4Signer::sign_http_request has been removed that only existed in my feature branch.

Checklist

• I have updated CHANGELOG.next.toml if I made changes to the AWS SDK, generated SDK code, or SDK runtime crates

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• No codegen difference in the Client Test
• No codegen difference in the Server Test
• No codegen difference in the Server Test Python
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• No codegen difference in the Client Test
• No codegen difference in the Server Test
• No codegen difference in the Server Test Python
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• No codegen difference in the Client Test
• No codegen difference in the Server Test
• No codegen difference in the Server Test Python
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.

[jdisanti]

SigningApplication is definitely an improvement, but still seems a little non-intuitive since it is a builder pattern that has a side effect.

What do you think about creating a trait, maybe SignWith, that has a sign_with method taking the identity/settings args, and then implementing that trait for http::Request?

[ysaito1001]

SigningApplication is definitely an improvement, but still seems a little non-intuitive since it is a builder pattern that has a side effect.

What do you think about creating a trait, maybe SignWith, that has a sign_with method taking the identity/settings args, and then implementing that trait for http::Request?

That's an interesting approach 💡 Let's discuss further. I'm curious.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• No codegen difference in the Client Test
• No codegen difference in the Server Test
• No codegen difference in the Server Test Python
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.

[rcoh]

should this target main instead? Is this related to S3 express?

[jdisanti]

I should have caught this in earlier reviews, but I think we should instead make SigV4SigningError an opaque/informative public error so that we can add methods to it in the future if we need to. See https://github.com/smithy-lang/smithy-rs/blob/main/design/src/rfcs/rfc0022_error_context_and_compatibility.md

It's pretty easy to do this. Just rename the existing error enum to "ErrorKind", and make a public struct with the previous name.

[jdisanti]

What's your reasoning for putting this in aws-runtime instead of aws-sigv4?

[ysaito1001]

I was under the impression that moving forward, we'll be putting items in aws-runtime-api and aws-runtime crates, but not in constellation crates, otherwise we can put it in aws-sigv4 instead.

EDIT:
A more practical reason was impl SignWith for HttpRequest referring to SigV4MessageSigner that is a private type in aws-runtime. Putting SignWith in aws-sigv4 and impl SignWith for HttpRequest in aws-runtime would violate the orphan rule.

[ysaito1001]

impl SignWith for HttpRequest internally uses a module private aws_runtime::auth::apply_signing_instructions, so we need to move it to aws-sigv4.

[ysaito1001]

should this target main instead? Is this related to S3 express?

It's just so happens that the S3 express feature branch was a convenient segue for this. But targeting main is actually better, since the S3 express feature branch doesn't need to hold onto these code changes. Will cherry-pick commits and create a different PR that targets main.

[ysaito1001]

Replaced by #3455