[AERIE-2142] Global scheduling condition in scheduling eDSL + mutex

[adrienmaillard]

• Tickets addressed: AERIE-2142
• Review: By commit
• Merge strategy: Merge (no squash)

Description

A global scheduling condition is an expression returning Windows associated to a list of activity types. When the scheduler is trying to insert an activity with a type in the list, and only in this case, the condition is evaluated. The condition is an expression of when an activity CAN be scheduled. It is combined with potential other expressions that reduces the intervals during which the activity can be scheduled (e.g. applyWhen, forEach in CoexistenceGoal...).

The mutex (mutual exclusion) in its general form can be defined for two lists of activity types. It postulates that activities with type in one of the list cannot overlap with activities in the other lists.

Now that I am writing about it, I'd rather call that noOverlap than mutex but this can be discussed, I do not know what term seems most natural. Anyway.

mutex([ A, B, C ], [D, E ,F]) means that any activity with type A or B or C can't intersect with any activity with type D, E, F. It is a relationship and it is reflexive = activities with types D, E, F can't overlap with A, B, C.

From this definition, a self-mutex can be defined as mutex([ A ][ A ]) which means that two activities of type A cannot overlap.

To implement this mutex condition, we use the Windows.Duringexpression defined in #402 and for each mutex we build two global scheduling condition objects.

mutex([ A, B, C ], [D, E ,F]) :=

gbs1 = {
expression = not(duringAny([ D, E, F]))
activityTypes = [A, B, C]
}

and 

gbs2 = {
expression = not(duringAny([ A, B, C]))
activityTypes = [D, E, F]
}

and we make a conjunction of them.

As you can see, the mutex condition needs two global scheduling condition to be enforced. And they are combined with an and operation (that is not yet available to the user).

In the scheduler server processing a conjunction of scheduling condition consists only in adding the elements of the conjunction in the set of global conditions.

Now the commits.

1. Generated activity types are exported from the ones generated from the mission model and used in the constraints.
   so we can use the same types in the scheduling edsl and the constraints edsl (global conditions are part of the scheduling edsl but use constraints internally).
2. I added GlobalSchedulingCondition class in the scheduling edsl and the corresponding node in the AST. There is also an GlobalSchedulingConditionAnd node in the AST.
   I have added three possibilities for the user to define scheduling conditions:
   a) scheduleActivitiesOnlyWhen(expression: WindowsEDSL.Windows) : building a scheduling condition with the given expression as well as ALL activity types from the mission model. This replaces what kind of existed before this PR where global scheduling conditions were defined only as an expression and were applying to all activity types.
   b) scheduleOnlyWhen(activityTypes: WindowsEDSL.Gen.ActivityType[], expression: WindowsEDSL.Windows) : building a scheduling condition with the given expression and the given activity types.
   c) mutex(activityTypes1: WindowsEDSL.Gen.ActivityType[], activityTypes2: WindowsEDSL.Gen.ActivityType[]): building the conjunction of global conditions described above.
3. parsers for these new nodes in the backend.
4. Remove notion of blacklist/whitelist in the GlobalSchedulingCondition in the scheduler. Use the conditions in the scheduler server. Tests.
5. Remove the default self-mutex on activity types that we put some time ago to ensure that the CardinalityGoal would "work" (not place all activities at the same start time in absence of other constraints).

Verification

Tests were added and many existing tests have been modified so they include self-mutex (that was previously defined by default).

Documentation

• Update the scheduling documentation when this is accepted.

Future work

UI for defining global scheduling conditions

[mattdailis]

Looks great - you've really become adept at wrangling the eDSL 💯

Holding off my approval until I can do a manual test - I'll try to do that right now.

[mattdailis]

After some manual testing, looks like this is working for me 👍

We can potentially remove the ActivityType enum from the generated scheduler code, since it's identical to the one in constraints. Here's a commit for what that might involve: b12563d

[adrienmaillard]

I have added your suggested commit in the branch @mattdailis, thank you.