Motivation

This PR implements the last missing integration: AWS. This integration allows API Gateway to interact with other AWS services, by constructing mostly manually a request following the service specs (APIGW will take of the signing and endpoint mostly, and in some case it helps directing the request to the right operation).

There are 2 kind of AWS integrations: path and action. The documentation is very sparse on those.
Path allows you to override the path where the request is sent, this can be used for services like S3 for example.
action allows you to target an AWS service action directly, and you might or might not need to give very specific data like the X-Amz-Target header to your request.

Before, we would specify a sub type of integration for each service, but after looking deeply into it with @cloutierMat, we realized it is only one integration in the end, with maybe a few differences between services but that are generalizable between services.
If things get out of control with specific behavior for the action type, we could register a "before send" and "after response" callback to fix the request/response before sending it for specific services. It's worth to say that there is literally zero documentation about the action type and which/how services are supported.

Which means we're now support way more services out of the box when using path URI! 🚀

By running all the AWS integrations test (which now all pass ✅), I've spotted a few bugs that have been fixed in the PR as well.

As a side note, this PR put into light the fact that AWS still supports the Query Protocol for the SSM service, and that API Gateway still sends request with that protocol by default to SSM... even though the botocore specs have always been the JSON specs. Fun 😬 \cc @alexrashed you might like that one...

Changes

• implement a generalized way to support AWS integration
  • support the path type which is very simple
  • for the action type, it is a bit more complicated and will still need a bit of effort to support new services, since it seems they fall into different categories.
• validate existing tests with AWS integrations (DynamoDB, SQS, SFn, Kinesis, EventBridge, Lambda, SSM and S3)
  • moved the SFn test into its own file
• change how we mapped default values for Content-Type and Accept for integration request (not passthrough but provided by AWS)
• implement rendering of URI, still need to implement more tests in the future
• skip needs_fixing tests for the new provider, as they often don't setup APIGW correctly
• last fix (last in list): fix the access to the REST API to be case insensitive when fetching the stage variables

Testing

Now with the new provider enabled, all APIGW tests only are passing locally! We will soon enable a new pipeline for the APIGW provider only.

Still 8 failing tests in the pipeline, fixed with #11198:

FAILED tests/aws/scenario/note_taking/test_note_taking.py::TestNoteTakingScenario::test_notes_rest_api
FAILED tests/aws/services/stepfunctions/v2/services/test_apigetway_task_service.py::TestTaskApiGateway::test_invoke_base
FAILED tests/aws/services/stepfunctions/v2/services/test_apigetway_task_service.py::TestTaskApiGateway::test_invoke_with_body_post[None]
FAILED tests/aws/services/stepfunctions/v2/services/test_apigetway_task_service.py::TestTaskApiGateway::test_invoke_with_body_post[]
FAILED tests/aws/services/stepfunctions/v2/services/test_apigetway_task_service.py::TestTaskApiGateway::test_invoke_with_body_post[HelloWorld]
FAILED tests/aws/services/stepfunctions/v2/services/test_apigetway_task_service.py::TestTaskApiGateway::test_invoke_with_body_post[request_body3]
FAILED tests/aws/services/stepfunctions/v2/services/test_apigetway_task_service.py::TestTaskApiGateway::test_invoke_with_query_parameters
FAILED tests/aws/test_multiregion.py::TestMultiRegion::test_multi_region_api_gateway