Actions Page Rework + Versioning + Archiving

[AaronPlave]

___REQUIRES_AERIE_PR___="1803"

Corresponding backend branch NASA-AMMOS/plandev#1803. Closes #1778

This PR moves the actions page into the workspace and introduces action+action definition versioning and archiving.

Workflows to test:

• Uploading multiple versions of an action and making sure that only the newest versions are used when running the action
• Archiving action versions and making sure that archived versions are not runnable (not even from re-run on action runs that used archived versions)
• Upload action versions with different settings keys and make sure that unused settings keys are deleted from the action definition settings object (check in hasura)
• Run an older version of an action and make sure that as many relevant settings are automatically filled out
• Make sure that only admins can create, update, and archive actions and action versions

TODO:

• A bit more UI cleanup and formatting
• Fix/update e2e tests

[dandelany]

UI notes from testing with @AaronPlave today:

• The action run logs have some weird formatting/collapse behavior if you log a line that contains BOTH text and a JSON object. Eg. logging {a: b, ...} on its own looks fine, but if you log myObject is {a: b, ...big nested object} the logs will have some funky formatting with a timestamp inserted halfway through:

• General UI thought was that the action run results page feels "too application-y" and "not enough like a report". We discussed combining things on to one report-style page, with sections in the following order: Errors, Results, Logs, Parameters (leaving off any that don't apply). I'll run this by @nat-sims before we totally commit to it.

[AaronPlave]

Does archiving resolve #1778's request to delete the action?

It should - we decided that archiving would be the primary action deletion method since hard deleting actions and action versions goes against the traceability requirements we have. If one of these truly needs to be deleted an admin can always go in and do it in the db. @dandelany

[duranb]

This function has some logic for adding some parameters. Can we extend its functionality to take action logic?

[duranb]

Actually, there's also a getActionsUrl that might be more appropriate. It might also need to be updated to account for the new routing for actions.

[AaronPlave]

Reworked this