Procedural Scheduling activity deletion

[JoelCourtney]

• Tickets addressed: closes Delete activities via Procedural Scheduling API #1594
• Review: By commit
• Merge strategy: Merge (no squash)

Description

This PR does two main things:

• allows procedural goals to delete activities
  • If the deleted activity has others anchored to it, they can choose whether to cascade delete them, reanchor them, or throw an error. Default is error
  • Unlike the UI, the ReAnchor option doesn't let you specify "reanchor to plan" vs "reanchor to grandparent". This is because allowing forced reanchoring to the plan is doesn't produce a predictable start time (see below). This unpredictability is more acceptable in the UI because the user will immediately see the results of their action and correct any mistakes. But in a scheduling goal, many activities might be updated unsoundly making it hard to fix the damage.
• Separates responsibility for satisfying the behavior guarantees of the editable plan interface into a reusable driver called EasyEditablePlanDriver. This way all the adapter has to do is translate the plan representations.

Unpredictability of re-anchoring

The timeline/scheduling procedural libraries try to keep track of an estimated start time for anchored activities, but it is not guaranteed to be right. In practice, I expect the estimates will usually be wrong due to the interop between eDSL and procedural; and even if an estimate is right, it can become wrong in the future. This can definitely be improved, but its a separate task and it will probably never be perfect.

This is usually fine because its an "unofficial" estimate. But if we have the activity chain A <- B <- C, and we delete B and try to reanchor C to the plan, we need to turn the start estimate into an official start time. This way too fallible and unpredictable to do automatically on a large batch of activities.

On the other hand, we could reanchor A <- C in a predictable and reliable way. Its still not necessarily accurate, because if the original state was A <- B (end)<- C then C will be shifted forward by the duration of B, because B is assumed to be instantaneous. So its not perfect, but its at least reproducible and predictable.

Verification

I've added unit tests for the changes to InMemoryEditablePlan, and e2e tests to make sure the changes are reflected in the database.

Documentation

I've added doc comments, and I'll open a PR for the docs website soon.

Future work

It turns out that implementing activity modification is so easy that I went ahead and did it in this PR, hidden in the backend. You'll notice in GraphQLMerlinDatabaseService that it not has routines for uploading creations, deletions, and modifications. The modifications part is used to update anchored activities during a deletion. I think extending support for this to the user will be almost trivial, but does deserve a separate PR.