Ensure instances are started after creation even with long running create processes WD-4050

[edlerd]

Done

• subscribe to events websocket to get live updates from LXD for any lifecycle changes
• use events to launch an instance that was created and is supposed to start.

Fixes WD-4050

QA

1. Run the LXD-UI:
   • On the demo server via the link posted by @webteam-app below. This is only available for PRs created by collaborators of the repo. Ask @lorumic or @edlerd for access.
   • With a local copy of this branch, run as described in the Readme.
2. Perform the following QA steps:
   • create or create+start some container and/or VMs and see the notifications work and the desired outcome is reached.

[webteam-app]

Demo starting at https://lxd-ui-360.demos.haus

[lorumic]

Suggested change

	console.log("Invalid format on event api: ", message.data);
	// TODO: remove this and other console.log calls
	console.log("Invalid format on event api: ", message.data);

[edlerd]

The log is for discovery of errors in the future. I wouldn't want to remove this in the future. I see we added this todo comment to various places where we handle websockets and think it should be removed there as well. Or how would this be useful?

[lorumic]

I don't understand what's special about websockets to justify these calls to console.log, which are discouraged for production code and a bad practice in general. They leak information about the app to the user.
Also, we don't apply the same error logging logic to, say, API calls, so I really don't see any good reason to make an exception here.
What we should really remove is these calls (and not introduce new ones), not the comments reminding us to clean up the code by removing them - sooner (better) or later:

Suggested change

console.log("Invalid format on event api: ", message.data);

[edlerd]

API calls that fail are prominently shown in the network tab in red. On failures, they are shown in the regular console.

Incoming messages on websockets are quite hidden under a WS tab in the Networks section and are prone to be overlooked. It is better to make the messages visible in the console if they are not handled than to drop them. The messages are not secret, because still discoverable with the debug interface of any decent browser - but a bit hard to find.

[lorumic]

Main point is: production code is not for debugging. You should not include any console.log there. Which is why I introduced those TODO comments in the first place. If you want to keep the debugging code in production code: fine, I'm just pointing out (for the last time) that doing so is not a good practice, and they should be removed if we want to have a clean, production-ready code.

[lorumic]

Just one small naming suggestion if you want, apart from that it's ready to go.