feat: add support for awsQueryCompatible trait

[dayaffe]

Related to smithy-lang/smithy-swift#850

Issue #

SWIFT-1865

Description of changes

• If a service is marked with awsQueryCompatible trait then requests will send an additional header x-amzn-query-mode set to true. This will tell the service to send back the x-amzn-query-error in response with error code and type information
• Since we do not currently expose Type/Fault we will not add it and continue to only expose Code
• If a service is marked with awsQueryCompatible trait operations will parse the value of the x-amzn-query-error and set the base error appropriate. This currently only applies to SQS which uses aws json 1_0 and thus only applies to AWSJsonError class.
• Create class AwsQueryCompatibleErrorDetails with unit tests to handle logic for parsing x-amzn-query-error
• Integration test is added to check for correct errorCode

New/existing dependencies impact assessment, if applicable

Conventional Commits

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[jbelkins]

Why does this need to be set after the AWSJSONError is constructed? Can't we pass errorDetails (or nil if not used) into the constructor? Alternatively can we roll the awsQueryCompatible logic into this constructor & pass in a Bool to indicate whether that trait is present? (The purpose of the BaseError type is to encapsulate protocol-specific error logic like this.)

That would allow us to keep this property immutable. Swift properties should generally be immutable unless there is a reason it must be changed after initialization.

[dayaffe]

I didn't feel right about changing the constructor for the general AWSJsonError just for a service customization used only by SQS. Will think if there's a better way to keep this as a constant

[dayaffe]

I'll have code passed in as an optional argument and then handle setting code in the extension function