save sso cache token expiresAt in UTC

[clhuang]

If the expiresAt field is saved with time zone (e.g. 2024-06-10T15:00:06-08:00) it will fail to load in certain SDKs such as the rust AWS SDK. To avoid this, ensure that it is always saved as a UTC format.

For changes to files under the /codegen/aws-models folder, and manual edits to autogenerated code (e.g. /service/s3/api.go) please create an Issue instead of a PR for those type of changes.

If the PR addresses an existing bug or feature, please reference it here.

To help speed up the process and reduce the time to merge please ensure that Allow edits by maintainers is checked before submitting your PR. This will allow the project maintainers to make minor adjustments or improvements to the submitted PR, allow us to reduce the roundtrip time for merging your request.

[lucix-aws]

Took another look at this, a few comments

• The new tests are fine but you didn't need to create a new suite -- we appear to have an existing one where this could have fit. You're welcome to roll them up or leave as-is
• I'd like to see some additional guarantees:
  • that we can still load the token that we save
  • that we can still load the token in both the 3339Z (changed behavior) and 3339+offset (original behavior) formats

The 2nd point may be covered by existing tests, I scanned them but may have missed one. Please either confirm their presence or add if missing

[clhuang]

I opted to not change the existing tests because the existing tests assert that the saved datetime object is the exact same as the loaded one, which is actually not the case when the token expiresAt is non-UTC. I would have to significantly refactor the existing tests and the use of cmpDiff.

[clhuang]

updated by adding a new helper cmpDiffToken that ignores time zone diffs in expiresAt