Extension mechanism

[Theodlz]

As is, SkyPortal does not provide the user with ways to easily connect to a data source/stream to populate the database with astronomical objects and other data products.

Ideally, we would like SkyPortal to be able to connect to any of the LSST public brokers. However, we do not want to force it onto the administrator and users that are in charge of a given instance. Also, how the data source is read & processed should be configurable.

One way to address this issue while making SkyPortal easily extensible & configurable is to add a concept of "extensions". Extensions are separate repos that contain:

• a supervisors config, that SkyPortal can append its own.
• a main.py file that runs the extension
• any additional python files or utils that the extension needs in order to run.
• a requirements.txt file that SkyPortal can read from on startup.
• a txt (or any other format) file to specify compatible SkyPortal versions, as well as the version of the extension itself. This could be done with github releases I suppose, so this text-like file is optional.

The extensions themselves would be listed in SkyPortal's config file, like so:

• name of the extension
• link to the extension on git, pointing to a specific hash.
• any additional configuration required for the extension to run
• any optional configuration that is supported by the extension

A first good example of this would be an extension to read from the Fink broker's alert streams, which has already been somewhat implemented for the GRANDMA collaboration SkyPortal instance: ICARE.

It will require us to move to semantic versioning for SkyPortal & Baselayer, and edit (mostly) baselayer to read the config.yaml file of SkyPortal, fetch the extensions, validate version compatibility, install dependencies, and append their supervisor config to SkyPortal's.