feat(proxy-sigv4-backend): migrate to aws-sdk v3 for js and remove deprecations

[alecjacobs5401]

Description

Gives the @segment/backstage-plugin-sigv4-proxy-backend plugin some much needed love and attention:

• fully leans into the new backend system for development servers
• fully leans into the new backend system interfaces and removes all deprecations
• migrates off of the aws-sdk V2 package in favor of the AWS SDK V3 for JavaScript packages.
• retains use of aws4 for SigV4 signing of requests. (has no aws sdk dependencies)
• replaces got implementation with node-fetch to satisfy https://backstage.io/docs/architecture-decisions/adrs-adr013/

Differences in this Approach

Credential Resolution

The way that credentials are resolved with @aws-sdk/credential-providers are slightly different now than before. The V3 package now has the concept of credential providers that return Promises that resolve to the necessary credentials. Credentials themselves are now a simpler type (essentially a Record). As such, it puts more of an onus on us to handle the refresh logic re-generate the credentials.

This also means that the contract for buildMiddleware had to change to return a promise. Before, credential resolution was synchronous, but now its async. This means that failure to assume credentials now will fail to register the route but let the app continue. We log a warning loudly about that, but its technically a difference in behavior since before a 401 or 5XX might have been returned instead of a 404.

I'm happy to adjust appropriately depending on what we feel is best.

Request Initiator

This PR swaps from got under the hood to node-fetch. As such, there are some differences in how Headers are handled since, apparently, every request library has a different idea of what headers can be.

aws4 requires the format of { [key: string]: string }, so we are normalizing values to that. I did some testing with API calls and multi value headers are typically comma-separated, so we're normalizing values to that.

I do not expect that to cause any upstream problems since the expected headers we're forwarding are so locked down anyways.

[alecjacobs5401]

I'll aim to do a release this week to get this out.