Add httpSigningMiddleware to authorize and sign requests

[syall]

Issue #, if available:

N/A.

Description of changes:

Add httpSigningMiddleware to authorize and sign requests.

Dependent on: #927, #928

If one or more of the packages in the /packages directory has been modified, be sure yarn changeset add has been run and its output has
been committed and included in this pull request. See CONTRIBUTING.md.

---

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

[kuhe]

what should someone encountering this error actually do to fix it?

[syall]

Note: this is all under the experimental flag experimentalIdentityAndAuth

This error is more as a precaution if the middleware was somehow used without httpAuthSchemeMiddleware.

httpAuthSchemeMiddleware (#929) should always be code-generated along-side with httpSigningMiddleware. httpAuthSchemeMiddleware throws an error if a HttpAuthScheme could not be selected.

---

There should always be at least 1 valid option if codegen-supported auth schemes in smithy-typescript are used, e.g. @httpBearerAuth, @httpApiKeyAuth, generic @aws.auth#sigv4. Other custom codegen-supported auth scheme implementations can also be provided (currently through the internal HttpAuthTypeScriptIntegration interface, which is subject to change).

If an auth scheme was not selected, it's likely:

• At codegen time, an codegen-unsupported auth scheme (e.g. a custom auth trait) was used, or
• The client was configured with httpAuthSchemes or httpAuthSchemeProvider values that didn't provide a valid selected HttpAuthScheme.

These cases should be very rare as they both require customization from either the customer codegen'ing the clients, or customizing client configs different from the default values.

Customers should probably not add custom auth traits or customize the client config values for httpAuthSchemes or httpAuthSchemeProvider without thorough testing.