Stopping JAPC subscriptions

The M.O. of the GUI is as follows at the moment:

• As soon as an environment is selected, it is initialized (self.selected_env = make_env_by_name(name, japc)).
• Every time the LSA cycle or the environment changes, we repeat this initialization.
• Environments are expected to subscribe to all their observables inside their __init__() method.
• Subscriptions are never stopped. Environments are merely eventually dropped and destroyed, at which point their PyJapc object naturally stops its subscriptions.

Our immediately next set of changes will hold onto this generaly architecture, but create the environment lazily in a background thread. This does not change anything about the order of operations – it merely makes the GUI more responsive.

We need to collect data on whether the current architecture brings any problems with it. Some questions:

• Is there a disadvantage to keeping the subscriptions running?
• Can we guarantee an orderly teardown and re-setup upon changing the environment?
• Can PyJapc handle subscriptions that are made off the main thread?
• Is there an advantage to splitting initialization into two phases? A cheap __init__() and a potentially expensive prepare_optimization()?

And here are some important tenets that we cannot work against:

• The GUI needs to manage and retain ownership of the PJLSA and the PyJapc client objects.
• Environments should see their subscriptions in complete isolation. They should be unable to observe subscriptions made by the GUI or other environments.
• The GUI may have to make subscriptions.
• Environments may want to use the PyJapc object in their get_config() and apply_config() methods.
• We don't want to force environment authors to write lazy semantics into their environments themselves.

added discussion label