Add and export types with the Validation error string literal values

[joneubank]

Summary

Add additional type exports that contain the validation reason string literal types. These are derived from the Validation Error union types so if new validation rules are added the Reason types will inherit the added reasons.

Description of Changes

Validation

Added four new exported types which are unions of the error reason literals, for programmatic reference by importing libraries:

export type FieldValidationErrorReason = FieldValidationError['reason'];
export type RecordValidationErrorReason = RecordValidationError['reason'];
export type SchemaValidationErrorReason = SchemaValidationRecordErrorDetails['reason'];
export type DictionaryValidationErrorReason = DictionaryValidationError['reason'];

which resolve, at the moment, as:

type FieldValidationErrorReason = "INVALID_BY_RESTRICTION" | "INVALID_VALUE_TYPE";
type RecordValidationErrorReason = "INVALID_BY_RESTRICTION" | "INVALID_VALUE_TYPE" | "UNRECOGNIZED_FIELD";
type SchemaValidationErrorReason = "INVALID_BY_RESTRICTION" | "INVALID_BY_UNIQUE" | "INVALID_BY_UNIQUE_KEY" | "INVALID_VALUE_TYPE" | "UNRECOGNIZED_FIELD";
type DictionaryValidationErrorReason = "INVALID_RECORDS" | "UNRECOGNIZED_SCHEMA";

Readiness Checklist

• Self Review
  • I have performed a self review of code
  • I have run the application locally and manually tested the feature
  • I have checked all updates to correct typos and misspellings
• Formatting
  • Code follows the project style guide
  • Autmated code formatters (ie. Prettier) have been run
• Local Testing
  • Successfully built all packages locally
  • Successfully ran all test suites, all unit and integration tests pass
• Updated Tests
  • Unit and integration tests have been added that describe the bug that was fixed or the features that were added
• Documentation
  • All new environment variables added to .env.schema file and documented in the README
  • All changes to server HTTP endpoints have open-api documentation
  • All new functions exported from their module have TSDoc comment documentation

[leoraba]

🎉

[justincorrigible]

this PR adds four new *Reason type aliases to @overture-stack/lectern-validation, but they're not re-exported from @overture-stack/lectern-client. is that something we want to consider? the curated list in packages/client/src/index.ts (i.e. already re-exporting these other existing types like DictionaryValidationError, FieldValidationError, etc.) doesn't include these new ones.

consumers likely import exclusively from lectern-client, not lectern-validation directly, so importing e.g. DictionaryValidationErrorReason the same way they already import DictionaryValidationRecordErrorDetails may be helpful (otherwise cause an error, or worse split where they import things from).

[justincorrigible]

worth a one-line comment here recording the deviation: the other three *Reason aliases all follow <X>Reason = X['reason'], but this one is derived from the nested SchemaValidationRecordErrorDetails instead, since SchemaValidationError itself has no top-level reason field... that's the right call, but undocumented it reads as an inconsistency rather than a deliberate exception, and a future contributor extending the pattern "by analogy" will likely hit some type error trying to do what "seems" obvious

[justincorrigible]

None of the 4 new exports in the PR have a TSDoc comment, which looks like it breaks with this file's own existing convention, FieldValidationErrorValueType right next to this one has one.

do we want to add a brief one-liner to each stating what the type represents?