GeezerVison

Motivation

TBD, stacked on of top #13151

This PR is part of a bigger initiative (see #13028) to implement support for the new Smithy Protocol smithy-rpc-v2-cbor, as well as the new Botocore multi-protocol support for single services (before, a service could only define one protocol).

This PR implements the new multi-protocol support for the CloudWatch service, by already implementing the future spec for the service as defined in https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-protocols-faq.html

The biggest part of this PR is the testing of the new specs: we will implement full multi-protocol testing of our entire CloudWatch test suite in a follow-up, but we are already testing that it can handle all 3 protocols (query, json and smithy-rpc-v2-cbor) by making requests via a plain HTTP client.

We also needed to update our dispatchers to 3rd party backends like Moto to be protocol-aware so that they would re-serialize and parse the incoming HTTP response properly based on the current request protocol. This meant some changes in signature of create_aws_request_context and parse_response.
For example, for the legacy v1 provider relying on Moto, CloudWatch with smithy-rpc-v2-cbor, we will get an InternalError from moto with ValueError: Bad status: 501, response body: {'__type': 'InternalFailure', 'message': 'Unsupported protocol [smithy-rpc-v2-cbor] for service cloudwatch'}
Note: I don't think we should try to adapt ourselves to what Moto supports, because there is no way to know from the specs what was the previous "default" protocol, so we would need to maintain a hardcoded list for those.

While implementing those tests, a few small issues came to light:

• when parsing UNIX timestamp, we would return naive datetime objects, however for other kind of timestamp format we'd return timezone aware object. This was an issue, and it is fixed in this PR
• when parsing Timestamp with our CBOR parser, the datetime could sometimes already be parsed so we shouldn't try to convert it twice (this couldn't be fixed before because ArcRegionSwitch does not define timestamp input)
• when serializing empty responses with our CBOR serializer, we would fail as we were looking at a non-existing shape
• CloudWatch would return Values as int instead of float in GetMetricData
• the parse_timestamp utility returned naive datetime objects

Note: current test failure is unrelated, will be fixed when new Pro version will be out

Changes

• implement the future spec for cloudwatch and add support for multi protocol
• add test suite to verify it works with all 3 protocols
• add additional small fixes:
  • fix naive datetime object parsing for unix timestamp
  • fix timestamp parsing in CBOR parser
  • fix serializing empty response in CBOR serializer
  • fix GetMetricData type of Values
  • update dispatchers to be protocol aware and update changed signatures in tests and usage
  • fix the parse_timestamp utility only used in S3 notifications and CloudTrail which was returning naive datetime even though the timezone data was encoded and should be used (put into light after the timestamp parsing of JSON)

Testing

I've also tested that it works with the beta version of the AWS CLI / botocore / boto3 that is available at the CloudWatch protocol FAQ

I followed the steps as given in the linked issue:

• checkout the PR and run it in host mode
• go to the downloaded folder from the link above
• create a venv and activate it
• run pip install boto3-1.39.7-py3-none-any.whl botocore-1.39.7-py3-none-any.whl awscli-1.41.7-py3-none-any.whl
• run AWS_ENDPOINT_URL=http://localhost:4566 AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test AWS_REGION=us-east-1 python -m awscli cloudwatch describe-alarms --debug
• verify that the request used the json protocol by checking its Content-Type or its CanonicalRequest in the debug logs:

   POST
   /
   
   content-type:application/x-amz-json-1.0
   host:localhost:4566
   x-amz-date:20250917T222501Z
   x-amz-target:GraniteServiceVersion20100801.DescribeAlarms
   x-amzn-query-mode:true