Reconsider the activity validation event process flow

The event trigger activity parameter validation change that we reverted causes the system to become bogged down when many activities are added to a plan. Large batches of activities can be added to a plan via after a scheduling run completes or via a mutation on the API. Currently a single event is fired for each changed activity. Additionally, the mission model associated with each activity is loaded and unloaded for each activity check. For example, I added 20K activities to a plan via the API, and it took Aerie ~2 hrs to work through all the activity validations. We will likely need to rethink the way we implement this capability.

Some initial thoughts: batch up/debounce changes against a mission model and validate all activities in a batch with a single mission model load and unload.

Depending on our solution options, if we are unable to resolve this burden on the system we'll need to roll back the change until we have a solution we are happy with.

Start by reviewing reverted pull request #370 and tracing the event-trigger validation flow for API mutations and post-scheduling activity batches. Compare the per-activity event and mission-model load behavior described here with possible batching or debouncing approaches. Done means the validation burden for large activity batches is resolved without requiring a rollback.