Implement a template class for observing proposals

[PaulHancock]

The current way that the triggering logic is coded and presented to the user makes it unclear what conditions are required to trigger an observing request for a given project. The triggering logic is spread across two locations in the code (the worth_triggering functions, and in the actual trigger calls themselves).

A proposed restructure of the triggering logic is as follows:

• Create a class Proposal which contains:
  • A short name and description of the proposal
  • A list of the event types that it will accept (from the gcn kafka service)
  • A list of the telescopes that it can issue observing requests for
  • A processing priority for the proposal
  • All the logic that is required to determine if a received event should cause a trigger. This should be a function such as worth_observing which accepts an event group, and returns IGNORE/TRIGGER/USER_INTERVENTION.
  • Functions called observe_mwa and observe_ATCA which contain all the information needed to make an observing request. These functions are called if worth_observing returns TRIGGER and the given telescope is in the list of telescopes that can be triggered by this proposal.
• The Proposal class is then used as a template for users to subclass and fill in / over-ride the relevant parts.
• When an event is received, each proposal is inspected and if the event stream is included in it's "accept" list then the event is parsed and passed to the worth_observing function for that proposal. The event is then logged. If no proposals list the event type then it's simply dumped as if it were never seen. (Alternative, subscribe to only events that are listed).
• Users can create these Proposal classes locally, test them (future feature), and then upload to the app for inclusion.
• Users can view all the proposals that are currently in the system. They can download them and replace them.