Add checks for parsing validate directive

[bobbyu99]

Description of changes

• updated @validate to be repeatable in both definition and snapshot test
• added validators.ts that checks for invalid use of validate directive, including:
  • the value for minLength maxLength is non-negative integer
  • specified validation type is compatible with the field type (string validation type for string field, numeric validation type for numeric field)
  • each validation type can only be used once on the same field
• renamed __tests__ correctly
• updated jest.config.js to ignore types.ts which has no executable codes, and to use globally defined coverage threshold

Description of how you validated changes

• unit tests for the validators
  • test that length value passed into minLength maxLength is valid non-negative integers
  • test that validation type is applied to compatible field type
  • test that we disallow duplicate validation types on the same field

Checklist

• PR description included
• yarn test passes
• E2E test run linked
• Tests are changed or added
• Relevant documentation is changed or added (and PR referenced)
• New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies
• Any CDK or CloudFormation parameter changes are called out explicitly

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[palpatim]

This is a surprising "pass" case to me. I assume that we will validate it because it parses into a number, but it will fail at runtime because it exceeds Java's Long.MAX_VALUE ?

[bobbyu99]

Let me check what the maximum/minimum value our resolver can accept

[bobbyu99]

This falls under a rare use case. We will use isNaN(parseInt(x)) until a customer complains about is.

[palpatim]

Nice catch

[bobbyu99]

I will also double check if Infinity is accepted in resolver

[bobbyu99]

This falls under a rare use case. We will use isNaN(parseFloat(x)) until a customer complains about is.

[palpatim]

Recommend we use the Number() constructor rather than parseInt, since I assume we want to catch invalid constructions like "10z.0". parseInt("10z.0", 10) returns 10, but Number("10z.0") returns NaN, which I think is what we want?

[bobbyu99]

Circling back to this conversation as I noticed that in default transformer, we do the following (link)

const validateInt = (x: string): boolean => !Number.isNaN(parseInt(x, 10));
const validateFloat = (x: string): boolean => !Number.isNaN(parseFloat(x));

This is currently the only place where we parse String to Number. I suggest that we keep numeric parsing consistent across both @default and @validate, so that it will not be a surprise to the customers that their parsing behaviors are different.