Allow Plan Bounds to be Changed

[Mythicaeda]

• Tickets addressed: Closes Change plan start and end bounds #1616
• Review: By commit
• Merge strategy: Merge (no squash)

Description

Adds a trigger to the Plan table to cascade updates to plan bounds to dependent tables
- specifically: activity_directive, simulation_dataset, and plan_dataset
- simulation bounds are NOT automatically updated by this trigger
- a snapshot is automatically taken when this trigger fires

Adds columns to the Plan Snapshots table to track plan boundaries at the time of snapshot creation

• updates the Create and Restore Snapshot functions to restore plan boundaries

Updates the "Update Plan Revision when Activity Directive is Updated" trigger to not fire if another trigger updates the activity_directive table

• Manually verified that the only trigger-originating update to Activity Directive is from the new trigger on Plan. All other updates to the Activity Directive table are either from function calls (ie commit_merge, delete_activity_by_pk_reanchor_subtree) or via user GQL requests
• If we want to avoid this update, we could pull the trigger function into a manually-called Hasura function, similar to how we handled model migration and keep the restriction on updating the DB column

Verification

TODO

Documentation

Future work

[dandelany]

Todo: write a test that checks that the activity relative time gets updated to maintain absolute time when plan bounds change

[dandelany]

Generally looks good - a few changes below. Hardest thing is figuring out to do with the cascading trigger problem mentioned below... @Mythicaeda will look into options

[dandelany]

Per review discussion, we are a bit nervous that preventing by depth is a "blunt instrument" that might have unintended consequences for other/future triggers. @Mythicaeda will look into other ways of targeting & preventing only the trigger we care about instead of any with depth > 1... If trigger relId or trigger tableName identifies it as coming from the plans table, we can use that to target

[dandelany]

Per discussion:

• we want to update sim bounds here (when updating plan bounds) - they are stored as absolute times
• if sim bounds match plan bounds before update - update them to match new plan bounds
• else:
  • trim sim bounds so that neither begin or end of sim bounds is outside of plan bounds
  • if sim bounds are entirely outside of plan bounds after trimming, just reset sim bounds to the new plan bounds

[dandelany]

We currently don't delete plan snapshots associated with a plan when the plan is deleted. As a result, if this migration is run on a deployment where "orphan" snapshots exist, these not null columns will be set to null and fail... @Mythicaeda will consider best solution