Review what happens at startup of application

[amitschang]

At the moment the startup of the application:

Reads config, which contains options enable_control and enable_commit which, if True means that the experiment will effectively start right away.

Some questions:

• Is this desired? If we have a power blip or other error which exits the application for a long-running experiment, this can continue it without manual intervention
• Should those options always be False, meaning that some intervention should be required?
• Should we take some action on all hardware (e.g. abort) at startup?
• Any other questions related to this?

[jamienoss]

Adding my take on things:

• the power blip scenario is best handled using a UPS rather than us hinging our design choices on it.
• control should NOT start automatically when the server startup - it should be manually started.
  • a rationale: the server hosts the UI which means that there's no time/interval for a user to inspect the config between powering up and control starting if the control automatically starts upon server startup. (Assuming the 12v is on)
• Resetting all hardware to some default rest/idle state, as is done via abort, upon startup, is a safe way to ensure lingering commands aren't persisted.

This could be most prevalent when switching between experiments/configs where hardware was configured in a previous experiment but not wanted in the new config, however, the now excluded hardware wasn't aborted correctly and is left lingering and active. However, since this lingering hardware will not be in the new (and now current config) there will be no way to reset it to an off/idle state, and it will still persist in its active lingering state.
From my understanding, there's no explicit notion that we've baked in, in code or convention/docs stating that the evolver config should ideally reflect all hardware connected regardless of whether it is intended to be controlled or not. Perhaps just mentioning this in the docs maybe sufficient to plug the hole.