DM-46002: Locations for validation errors on constraints reported incorrectly

[JeremyMcCormick]

This fixes an issue where the Pydantic error locations for constraint objects were reported incorrectly, due to how the model objects were constructed.

Instead of using a custom create_constraints() function, a Pydantic discriminated union was used to automatically construct the objects based on the type field. This seems to fix the issue where error locations were reported incorrectly.

Sample new error location is: tables.0.constraints.0.Unique.@id.

This is not exactly the same scheme that shows for some other types of objects, but it is at least clear now that the error has occurred in a specific constraint denoted by the index.

As a result of the above changes, usage of the type field in the metadata and tap modules was removed in favor of checking the constraint's type using isinstance(). This is required based on removal of the type field from the Constraint class. (Since it should never be instantiated, the type field is not needed on this class and including it creates typing conflicts with its child classes. Each constraint class now defines this separately and not as a common field from the parent class.)

A few additional changes were included which do not have associated tickets:

• Cleaned up the Constraint test case in test_datamodel (See 1706788).
• Added check to the data model that the deferrable field on Constraint must be set to True if initially is not None. This requirement was indicated in comments but never implemented.
• Added a Literal to Constraint in the data model that limits the value of initially to IMMEDIATE or DEFERRED as these are the only valid values for an INITIALLY clause in DDL.
• Removed the unused annotations field on the Constraint class. (This field was erroneously carried over from the old "simple model" but has never been used within a production schema, to my knowledge.)
• Cleaned up the Index test case in test_datamodel (See 6631610).

Checklist

• Ran Jenkins
• Added a release note for user-visible changes to docs/changes

[codecov]

Codecov Report

Attention: Patch coverage is 98.83721% with 1 line in your changes missing coverage. Please review.

Project coverage is 91.01%. Comparing base (364fc5c) to head (f8b514d).
Report is 10 commits behind head on main.

Files with missing lines	Patch %	Lines
python/felis/metadata.py	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #102      +/-   ##
==========================================
+ Coverage   90.92%   91.01%   +0.08%     
==========================================
  Files          16       16              
  Lines        1885     1881       -4     
  Branches      417      410       -7     
==========================================
- Hits         1714     1712       -2     
+ Misses         97       96       -1     
+ Partials       74       73       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[gpdf]

I have to admit to not being qualified to review the Pydantic details involved here; the goals seem appropriate and I'm willing to accept that the resulting messages are improved in their intelligibility.