[V4] Adjustments to fix failing DateTimes asserts in tests due to local/UTC inconsistencies.

[boblodgett]

Description

When running tests locally the following tests were found to be failing:

• TestParsingResponse_200Result
• TestDateTimeDeserializationWithDdbContext
• StaticStabilityWhenIMDSExperiencesAnOutageScenarioTest

These were not caught running dry-run on the server previously because the server was set to +0 timezone offset (UTC) so local and UTC times were effectively the same.

TestDateTimeDeserializationWithDdbContext

This was caused from our intended breaking change of DynamoDB RetrieveDateTimeInUtc has been switched to true as the default.. Because the dates were being returning in UTC and the input dates were being passed as local the assert comparisons were failing. Required a test update.

TestParsingResponse_200Result

Required adding back in the .ToUniversalTime() removed from a recent PR (#3541). Public properties such as Expiration should be UTC but there is no guarantee they will be if they can be publicly set. The .ToUniversalTime() defensive call has been added back in.

StaticStabilityWhenIMDSExperiencesAnOutageScenarioTest

Required adding back of .ToUniversalTime() and in addition adjustments to EC2InstanceMetadataServlet for invalid mocked responses. The code was using JsonMapper.ToJson(from an object containing a UTC datetime) but because of the default datetime export handling in the mapper mocked IMDS service was setting the expiration as a datetime string without the Z even though it was a UTC expiration datetime. This cause the response parser to assume it was an unspecified datetime which then got double converted to UTC with the reintroduced .ToUniversalTime() call.

Added in code to override the datetime export handling for EC2InstanceMetadataServlet to return the properly formatted datetime strings with a Z.

Motivation and Context

Testing

dry-run: DRY_RUN-ed208a00-5381-46b7-a858-ad97c0247863 (Succeeded)

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have read the README document
• I have added tests to cover my changes
• All new and existing tests passed

License

• I confirm that this pull request can be released under the Apache 2 license