otelaws: Add finalize middleware after instead of before

[jacksehr]

This PR addresses #3368.

Summary

In any presigned URL flow, the AWS SDK skips all Finalize middlewares after the PresignHTTPMiddleware. So, if we move context propagation after the PresignHTTPMiddleware, we will not include context propagation headers in presigned URL requests, which should prevent the reported issue with signatures.

Context

The existing middleware in this package adds propagation headers (e.g. traceparent) to outgoing AWS requests, presumably to be used in things like AWS X-Ray. However, when making requests for presigned URLs, the AWS SDK adds a bunch of middleware of its own to requests. The most important of these is the PresignHTTPMiddleware. This does a lot of things, but for the purposes of this PR/issue, there are two particularly relevant things it does:

Incorporating request headers into the presigned URL signature

When it is built, the middleware receives a presigner. Then, when it is actually run, it receives a *smithyHTTP.Request, and it's entirely up to the presigner if the headers on the *smithyHTTP.Request are incorporated in the calculation of the presigned URL's signature. If we look in the internals of the default v4 signer, it appears to just incorporate all existing headers and use them to sign the URL. This leads to the problem described in the above issue:

The URL generated from code with otelaws middlewares has two values host and traceparent, while the one without otelaws middlewares has only host.

As observed by the comments in that issue, disabling the context propagation solves this issue, which makes sense as that removes the traceparent header from the signature calculation.

This leads us to the second relevant behaviour of the PresignHTTPMiddleware.

Short circuiting remaining middleware

From the comments of the PresignHTTPMiddleware:

// PresignHTTPRequestMiddleware provides the Finalize middleware for creating a
// presigned URL for an HTTP request.
//
// Will short circuit the middleware stack and not forward onto the next
// Finalize handler.

In addition to this, the Deserialize middlewares get cleared, as seen here.

So, in the presigned URL flow, the last middleware that will get called will be the PresignHTTPRequestMiddleware. This is actually useful for us now, as if we just ensure our context propagation middleware comes last in the Finalize step, then we can be sure it will never run in the presign flow. Simply shifting from middleware.Before to middleware.After does just that.

I've also renamed the function and moved it so that its order reflects the order of middleware execution (i.e. finalize before deserialize)

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: jacksehr / name: Jack She (bf5da4b, 2d44e0d, af69eb4, f25e56e, 4559445, dfa28bb, 3a41822, 6a68bf4, 2c7342a, 659de52, 124ab3d, 082cb53)

[pellared]

@akats7 PTAL as a code owner.

[akats7]

Hey @jacksehr, will take a look at this later today, thanks

[akats7]

Hey @jacksehr, can you please resolve the issues in the unit tests to use your updated method, also would you be able to add/update a test case to reflect this change.

[akats7]

Hey @jacksehr, any update on this?

[jacksehr]

Hey @jacksehr, any update on this?

Hey @akats7, sorry for the delay, circling back to this -- I've updated with a test and resolved the compilation issue.

[pellared]

Please add a changelog entry