Sound lifetime management of components and up to date status monitoring information

[AustEcon]

The current for tracking the status of running components is (and will be when complete):

• a AppData/Local/ElectrumSV-SDK/component_state.json file (with a file lock) is updated -> ComponentState.Running
  on successful launch (determined by polling / health check)
• then the status monitor will continue polling the running components to ensure that ComponentState.Running is still true...
  if not then it would update component_state.json -> ComponentState.Failed for as long as the health check is failing. If the component comes online again then updates -> ComponentState.Running.
• However, if the component is explicitly stopped then component_state.json -> ComponentState.Stopped.
• Therefore the true status should be never any more than 1-2 seconds out of date at any given moment.

If the status_monitor is offline (it is optional). Then the ComponentState (Running / Failed / Stopped) are unreliable datapoints.

But the other contents of the component_state.json are always valid (such as the pid, component id, etc. etc.) and can be used to reliably stop / start / reset the components (the status monitor does not need to be online for this core functionality)

Alternative model as discussed with rt (Unsure if it is possible though).

• To have the status_monitor promoted to take on more responsibility. Namely, the launching of applications such that they can block in a thread (using subprocess.Popen() calls)...
• To make this workable we would need a way to pass environment variables to the subprocess.Popen() and a way to capture the return_code and stdout if the underlying server crashes or exits.
• Would also need a way to run in background OR spawn a new console window with the above still holding true
• Would also need a way to redirect the logs if running in the background.
• The advantage of this is that it allows immediate and robust feedback when a spawned application crashes and returns the traceback + update -> ComponentState.Failed immediately, rather than relying on (a potentially tenuous) polling / health check system over the network.

As discussed:

• We will stick with the current model for now but perhaps revisit this as at a later date.