Add new shapeExamples trait that communicates and enforces allowed and disallowed values

[brandondahler]

Background

• What do these changes do?
  • Adds a new @shapeExamples trait which defines the set of allowed and disallowed values for a given shape.
  • Updates the NodeValidationVisitor to be more accurate in some less-commonly used cases
  • Adds a new ShapeExamplesTraitValidator implementation which verifies that:
    1. Allowed values are accepted by the shape based on the configured constraints
    2. Disallowed values are not accepted by the shape based on the configured constraints
• Why are they important?
  • Configuring and modifying a shape's constraints is tedious work with potentially large consequences if mistakes are made.
  • This is especially true for @pattern-based constrained values
  • This feature offers a mechanism to both express your intent as a shape author about what you meant to configure while also enforcing that the intent is a reality during the model validation phase.

Testing

• How did you test these changes?
  • Significant effort was put into building out an ErrorFilesTest-based suite of tests to ensure that the validation works across as much of the gamut of constraint and shape type combinations that exist.
  • Documentation updates were best effort -- I do not have an environment setup that is readily capable of building and inspecting the output.

Links

• Links to additional context, if necessary
  • Implements Feature request: Support for defining and verifying positive and negative test vectors for constrained shapes and members #2821

---

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

[brandondahler]

Updated implementation here to make it easier to iterate on error files -- the previous implementation would output the extra file location information and hints if they exist, which are explicitly omitted from the errors file normally.

You can now copy+paste directly from the failure message in the test result into the errors file.

[brandondahler]

Originally traversing into the shape when the value was null pretty much guaranteed that an error would be reported -- generally of the form "<string, number, object> was expected but value was null" (not exact wording).

Since is the memberShape method, this only affects aggregate types which have an explicit null value as opposed to the member being omitted.

[robin-aws]

nit:

Suggested change

	allowed: ShapeExampleList
	disallowed: ShapeExampleList
	valid: ShapeExampleList
	invalid: ShapeExampleList

AFAICT "valid" appears a whole lot more in the spec/documentation than "allowed"