Support persistent sharing of a Targets data with destinations

[jnation3406]

Effort: 3

Description:

As a TOM user, I would like to be able to select a target to persistently share its data with a sharing destination as new data comes in. Right now we support manually clicking a button to share to a TOM or HERMES topic, but this work would be to set up a new Model to store target groups and sharing destinations, and then check that model when new data comes in to automatically share it with any destinations associated with that target. We may want to store some additional information in the PersistentShare instance, such as whether its enabled, a time limit when it should stop being used (?), and perhaps the user that created it (to include with shared messages).

Add a setting in DATA_SHARING destinations for persistent_sharing_classpath to let users set a class that determines if new data should be shared.

When new data comes in, check that it wasn't already ingested in its "messages" for that destination before sharing it there.

Tasks:

• [ ] Add PersistentShare model in tom_targets, referencing a target group and a sharing destination
• [ ] Add view to create/view/delete persistent shares for a target group
• [ ] Create a signal handler on ReducedDatum creation to trigger sharing that reduced datum with any destinations that have a corresponding Persistent Share setup with that datum's target

[jchate6]

I think this is an excellent feature. One comment is that the rest of the sharing functionality (sharing.py) is stored in tom_dataproducts. It might make sense to keep this code together, especially considering my next question.

Should this be more generalized than only triggering on a target? Not every science group prioritizes sharing data updates for existing targets. Quite often new targets or kind of data product (spectra from x facility, for example) or the results of certain catalog query might be the trigger for sharing data.

If that's outside the scope of this story, or the answer is adding model fields as those use cases are requested, I'm perfectly happy with that answer, I just wanted to throw that consideration out there.