Access resources from mission model in procedures

[JoelCourtney]

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

Description

This PR lets goals and constraints query resources by referencing them through the mission model. Meaning you can write simResults.resource(model.fruit) instead of simResults.resource("/fruit", Real.deserializer()), where mission is a valid instance of the mission model.

• Vile hack No. 1: The goal/constraint gets the instance of the model through the WithModel<M> interface, which has a mutable static field modelSingleton. The scheduler or constraint action creates an instance of the model with the default sim config and sets the sim config at the beginning of the action. Goals/constraints that inherit from WithModel<M> can then get that instance with this.model().
• Vile Hack No. 2: The only code this adds to the mission model is a NameableResource interface and NamedResource abstract implementor of that interface for convenience. Concrete resource types can inherit from NamedResource, which just lets the Registrar call NameableResource.setName(string). This happens during the model constructor, so it happens both during simulation (which is useless) and during scheduling/constraint actions. The timeline library SimulationResults then provides a few resource(...) overloads that look for things like NameableResource<RealDynamics>, NameableResource<Boolean>, etc. It calls NameableResource.getName() and associates the payload type with a timeline type like Real, Booleans, etc.

This required some fiddling with ClassLoaders to make sure that the mission model was not loaded twice by different loaders (which isn't just a waste, it also causes a class cast exception).

Verification

I've made two integration tests, one for scheduling and one for constraints. I've also manually verified that the constraint/goal jars don't include the mission model. (unzip -l <jar> | grep banana)

Documentation

I swear I'll update the guide docs this time.

Future work

Because Vile Hack No. 1 creates the model with the default sim config, this could cause some issues when we support other configs during scheduling. I'm assuming that the default config corresponds to the full model with no resources left out.

[sonarqubecloud]

Quality Gate passed

Issues
22 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
2.5% Duplication on New Code

See analysis details on SonarQube Cloud