Bug: Temporary view shown before node has started

[danielnordh]

When a user is onboarded, StartView briefly shows a screen with a button offering a way to go back to Onboarding.
It happens both on first run, and subsequent app starts.
This could be a regression from my work in #131

Here is the UI Code being shown:

It seems to be caused by BitcoinView not being launched until node is started, and the start is not triggered until StartView .onAppear.

I'll look into how to avoid this happening.
Potentially having LDKMondayApp observing whether a node is started instead of whether 'onboarding' is true.
This could enable bypassing StartView completely and showing BitcoinView when node is started.

If that is not possible, or a good idea we can do a visual workaround in StartView.

[reez]

I don't think this is a bug just a weird workaround needed previously. I'll add some more context in a bit on the problem that this solution was addressing, but there is definitely a better solution to figure out for it indeed.

[reez]

Context: same time period that I added the "reset preferences" stuff we discussed yesterday, similar issue(s) to try to work around

Problem: Esplora not working

(Temporary) Solution: Give a "loading" screen that is minimally noticeable when things work right, but if things aren't working if node is stuck loading (because the Esplora provided to it isn't working, and client app may not know that) user can get back to the start of onboarding to select a different Esplora.

Reproduce: to reproduce what would happen in this case you can mimic it by changing https://mutinynet.com/api to https://mutinyne.com/api (remove "t")

Further thoughts: definitely not the ideal solution, but at the time did not know if the underlying Esplora problem would be a a temporary problem or long term problem. I think we touched on some overall onboarding thoughts yesterday with breaking out the build from init https://github.com/reez/Monday/blob/main/LDKNodeMonday/Service/Lightning%20Service/LightningNodeService.swift#L88, which would further the ability for what would probably be a better onboarding where some of these steps could be broken out a bit more (example: if esplora is the problem, break out esplora selection into a separate screen where the underlying functionality can handle an esplora problem before passing a non-working esplora into the node builder). What was extra tricky about this at the time was the app would not crash, but would also not get notified of an error with the esplora either.