Stateless Aerie - Scheduling

Description

Per discussions with @ewferg, some users would like an officially-supported way to use Aerie's simulation and scheduling engines as a simpler "stateless" and "headless" program.

• Stateless means the user runs Aerie simulation/scheduling with some inputs, Aerie exits and returns some output, but nothing is persisted in the Aerie app/DB beyond that point - as opposed to our current standard Aerie deployment, which is a persistent web service
• Headless means without a UI, ie. likely a CLI which reads from stdin and writes results to stdout when complete.

Requirements

We don't yet have all of the requirements or implementation fully planned out yet, but I wanted to open this to track our progress. I will meet with @ewferg soon to discuss - please comment here or in Slack if you're interested in participating. As a starting point, here's a rough draft of some requirements:

1. Users should be able to run Aerie's simulation engine alone in a stateless way, by running a command and providing two inputs: a mission model JAR file, and an Aerie plan file containing activity directives. Aerie should run the simulation, output any useful results (grounded activity instances, profiles, other TBD?) and exit.
2. Users should also be able to run scheduling alone statelessly, by running a command and providing a mission model, an Aerie plan, and scheduling goals as inputs. Aerie should execute the scheduling goals (possibly running more simulations in the process), output useful results, and exit.
3. For a reasonably small model/plan/set of goals (to be defined), stateless simulation should be able to run in < 10 seconds, and stateless scheduling should run in < 30 seconds, to be competitive with existing tools that users are using today instead of Aerie.

Notes & Questions

• Our first goal is to determine how feasible this is given our current architecture, & the level of effort it will take. Once the requirements are further fleshed out, we'll meet with devs to come up with a proposed implementation.
• Can stateless sim/scheduling be done without running our (hasura/postgres) database service, since nothing is being persisted, or is the DB too tightly coupled to Aerie sim/scheduling for this to work? The performance requirements will be difficult to meet if we have to wait for Hasura's significant "spin-up" time.
• Stateless scheduling will be required to support procedural scheduling JARs. Does it also need to support EDSL goals/interleaving like the UI does?
• Is there any overlap here with aerie-cli functionality, and should we consider taking ownership of aerie-cli and implementing this feature there, or is this a part of Aerie core, or a new tool altogether that interfaces with Aerie core?