Time systems plugin

[AaronPlave]

Introduces a client side plugin API for time input and display in the plans and plan pages. The UI will now look for a time-plugin.js file in the static/resources directory and the UI will load the file if available. This javascript file will supply an async getPlugin function that provides a partial set of functions and objects according to the plugin type. The plugin can load additional files from the static/resources directory if desired.

UI plugin examples repo: https://github.com/NASA-AMMOS/aerie-ui-plugin-examples

Closes #503

Setup:

• Clone the https://github.com/NASA-AMMOS/aerie-ui-plugin-examples repo or download the time-plugin.js file in each example folder along with any other files in the LMST build directory.
• The UI will use the new PUBLIC_TIME_PLUGIN_ENABLED=true env variable to determine whether or not to fetch the time-plugin.js file from static/resources. Add this to your .env and/or to your aerie backend docker-compose file.
• For local development:
  • Update the env with the new variable
  • Create a resources directory in the aerie-ui static directory and copy the built example files (choose the LMST plugin to start with) into resources. For LMST, the kernel files should be kept in a kernels subfolder, mirroring what exists in the plugin.
  • Run dev server as normal
• For dockerized deployment:
  • Add the new env variable to the UI container section of the docker-compose file
  • Mount the following volumes to the UI container (change the paths to reflect where you put the plugin files):
  • ../aerie-ui-plugin-examples/examples/time/lmst/build/:/app/client/resources/
  • ../aerie-ui-plugin-examples/examples/time/lmst/build/resources/kernels/:/app/client/resources/kernels/
  • Run aerie as normal

Testing:

• Perform the setup for both dev and dockerized environments and ensure that you can see dates being displayed and formatted with LMST on both the plans and plan pages. A "plugins loading" message should appear on each refresh of either page.
• Remove/rename the time-plugin file to force a plugin loading failure and ensure that the UI shows a failure toast but continues to operate normally
• Repeat the setup using another plugin example

TODO:

• [ ] Code walkthrough
• [x] Support a default plan duration in MS in plugin and a formatter for plan duration (ms -> string)
• [x] What should this be called? A plugin? Time adaptation? Should any of this code be generic to hint at some sort of future expansion for plugins? -> Plugin
• [ ] Figure out how to load the plugin once on plan/plans page and not have to reload it when navigating to other pages and then back
• [x] Error states and messages for plugin? -> Block interaction
• [x] Figure out if a store is the best way to house and call the plugin
• [x] Figure out if there should be a limit to the number of additional formats allowed
• [x] Figure out if we need to allow users to customize which additional formats are displayed in timeline and elsewhere in V1
• [x] Figure out if we need to indicate that durations are still in Earth times now that we support user supplied times -> no except for maybe plan duration
• [x] Figure out if there's a better way to load the plugin than on page load -> not at the moment
• [x] Plugin loading state design - should it block the UI while loading or should we try to make it as invisible as possible? Depends somewhat on expected load time for plugins. Current LMST plugin example loads very quickly but it's possible that other users may need to load more/larger resources over several seconds. -> block app entirely during loading
• [x] Figure out and test mounting static/resources in docker container
• [ ] Rework all date picker usage to reflect plugin and/or make a plugin aware date picker component to abstract some of this
• [ ] Documentation for this approach and document the example repo
• [ ] Make an issue for when a user zooms too far in timeline and causes invalid time range (not related to plugin work)