More resilient taker startup behaviour - there should always be a UI (and even if it's just in an error state)

[scratchscratchscratchy]

At the moment, when the taker starts up and something "goes wrong" the application will just fail - the UI will never become available in such scenarios.
This includes any error of an actor during startup. One example is e.g. the wallet not being able to connect to Electrum (because it is misconfigured or not in sync yet), which will just lead to the daemon crashing (and hence the UI is not served).

I think, eventually, the UI should always be served - and the user should get feedback about what happened.
Especially when integrating into platforms like Umbrel this paradigm becomes important, so I think we should start incorporating it into our architecture design.

Thoughts?

[thomaseizinger]

Our feed model requires us to be declarative. Sending "updates" or "events" to the UI doesn't really work particularly well.

We can model this kind of problem by having a dedicated feed that represents the "health" of the system:

interface SubsystemStatus {
	Offline,
	Online,
	Connecting
}

interface SystemHealth {
	maker: SubsystemStatus,
	bitmex: SubsystemStatus,
	core: SubsystemStatus, // core = actor system
	oracle: SubsystemStatus,
	electrum: SubsystemStatus
	// ...
}

The UI can provide actions to the user based on the sub-system state. We can - for example - try to connect to the maker or bitmex a number of times but give up after - say - 5 retries.

[thomaseizinger]

Incorporated into the vision document: https://github.com/itchysats/itchysats/blob/master/docs/VISION.md#always-available-ui