feat(smithy-client): support strict timestamp parsing

[adamthom-amzn]

Description

From context, we know what the format of a timestamp should be, and we can
restrict the input to match that format rather than relying on the unspecified
behavior of new Date(string).

Testing

Unit tests, plus regeneration of clients, client protocol tests, server protocol tests. (those PRs to follow)

Additional context

• We generally try to avoid adding dependencies, which is why I wrote these functions here, but there's potential for even more verification (like day of week) that I'm avoiding altogether that we might not have to with a real date/time library.
• We could write a more performant parser without using regex, but getting the behavior and abstraction right first is more important to me.
• I was split between putting these in date-utils or parse-utils, I'm open to suggestions.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[AllanZhengYP]

I didn't look very deep into all the date RFCs, only a few minor points to the syntax. You can leave the function in date-util. Otherwise, most other function in the smithy-client are parser-util.

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (main@afeccd7). Click here to learn what that means.
The diff coverage is n/a.

❗ Current head 6aae1ae differs from pull request most recent head 7cf40f7. Consider uploading reports for the commit 7cf40f7 to get more accurate results

@@           Coverage Diff           @@
##             main    #2737   +/-   ##
=======================================
  Coverage        ?   61.48%           
=======================================
  Files           ?      540           
  Lines           ?    27617           
  Branches        ?     6745           
=======================================
  Hits            ?    16981           
  Misses          ?    10636           
  Partials        ?        0           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update afeccd7...7cf40f7. Read the comment docs.

[JordonPhillips]

I put this in a few spots, but you're gonna have to account for leading zeroes being valid all over the place, where the strictParseX methods explicitly reject them. It'd be great if you could just use the built in parseInt but that'll probably take a single leading zero as an octal.

[JordonPhillips]

Whoops, meant to do request changes

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.