Versioning Constraints - DON'T MERGE without UI

[Mythicaeda]

• Tickets addressed:
  • Closes Store versions of constraints #1238,
  • Closes Remove ability to associate constraint with a model #892,
  • Closes Evaluate only a specific version of plan level constraints #1239,
  • Closes Make sure constraint names are unique #882 (for public constraints)
• Review: By commit
• Merge strategy: Merge (no squash)

Description

This PR is essentially an overhaul of how constraints were represented in the DB.

Below is a breakdown of the changes. Keep in mind when discussing permissions that unless a permission explicitly addresses the aerie_admin role, assume that it doesn't apply.

1. The constraints table has been replaced by the constraint_metadata and constraint_definition tables. The constraint_definition table contains the various versioned definitions of a constraint, while constraint_metadata contains the metadata consistent across all definitions (ie the name of the constraint). Once a version is created, it can only be updated by an admin user. The owner of a constraint can freely delete unused versions (see 3). Any user can create versions of public constraints (see 2). Both the overall constraint and each specific version can be tagged.
2. There is now the concept of public vs private constraints. All constraints start private unless otherwise specified and can be freely toggled between public and private. All public constraints must have unique names, but private constraints can have names that overlap. Only the owner of a private constraint can make new versions, and any user can make new versions of a public constraint. Only the owner of a private constraint can add it to constraint specifications (see 3), but once a private constraint has been added, any user able to edit the specification can freely manage the entry on the specification. Any user can add public constraints to constraint specifications they have permissions to manage. A constraint cannot be SELECTed unless it is public, or the user doing the SELECT either owns the constraint or can manage a constraint specification it is on.
3. There is now the concept of a model and plan constraint specification, which replaces the former concept of "model constraints" and "plan constraints". A model specification is a recommended set of constraint and constraint versions for all plans using the model. A plan specification is the set of constraints that are checked during the action. If no version is specified (referred to as "version locking" in the tests), the latest version will be used. If a constraint is disabled on the specification, it will not be checked. When a plan is created, its constraint spec is prepopulated with the constraint spec of its model.

QUICK LIST BREAKING CHANGES:

• The structure of the return type for the CheckConstraints action has been altered:
  • the type field has been removed
  • the constraintRevision field has been added
• The constraints table has been split into two tables: constraint_metadata and constraint_definition. Additionally, plans and models now have constraint specifications. Any GQL queries referencing the constraints table will now need to reference at least one of these four tables, with which specific one varying based on what the query was doing.

Verification

DB Tests:

• The DB Tags Tests were updated to test the new tags table
• Inserting a constraint in the DB has been updated to not depend on plans

e2eTests:

• Tests that checked/depended on definitionOutdated were removed
• ConstraintsTests for versioning and enabling/disabling constraints were added

Documentation

Open Docs ticket

Future work

Scheduling Goals need to be changed in a similar way

[Mythicaeda]

Change just pushed was to tweak the Hasura Metadata to allow users to add and view all constraints on the plan's model spec, even if they are private. Users would've had issues when syncing their plan to the model spec without this change.