Procedural Constraints Database Support

[skovati]

closes #1572

Description

Mirroring the database changes that were made for procedural scheduling support, this PR makes the following changes to the constraints sub-schema in merlin:

• an auto-generated ID invocation_id was added to constraint_specification and made the new (sole) primary key. This allows for multiple "invocations" of that same constraint definition in the same spec.
• type enum, uploaded_jar_id, and parameter schema fields were added to constraint_definition to support procedural constraints
• definition was made nullable in constraint_definition, since it will be null when that constraint's source code is contained in the uploaded jar.
• constraint_run now holds an additional field, constraint_invocation_id, which replaced (constraint_id, constraint_revision) in the primary key definition. This is so we can have a constraint run for each invocation in a plan spec, which might share constraint definitions and revisions.
• constraint_run also holds the "as run" arguments that were passed to the constraint during execution in a new json field arguments.
• merlin server was updated to comply with these schema changes
• e2e tests were updated to comply as well

Verification

WIP

Documentation

Future work

[skovati]

Active works in progress:

• database migrations
• comments for new tables
• verification of migrations against real data

[Mythicaeda]

Blocking: This pkey is not sufficient. If the user decides to check constraints twice, updating the definition of a constraint between checks, they will get a pkey conflict when the action attempts to cache the output of the second definition.

(This comment is here to prevent me from not fixing this)