Improve error handling and UI for launcher "offline"

[Steve-Mcl]

closes #1083

Description

• Curates the error responses from the launcher to provide better info to the frontend (prevents the default technical "catch all" Error 500 toast notification)
• Makes the toast message more friendly and ONLY displays it once
• Adds a friendly / less alarming banner above the log panel to inform users that the logs are currently unavailable
• Stylises the log panel to indicate it may be stale
• Adds a timer mixin for controlling polling
  • This was something discussed in a meeting some time back. This component can be (should be) reused wherever polling is required as it can be easily controlled and automatically stops when component is unmounted etc.

logs-offline.mp4

Related Issue(s)

#1083

Checklist

• I have read the contribution guidelines
• Suitable unit/system level tests have been added and they pass
• Documentation has been updated
  • Upgrade instructions
  • Configuration details
  • Concepts
• Changes flowforge.yml?
  • Issue/PR raised on flowforge/helm to update ConfigMap Template
  • Issue/PR raised on flowforge/CloudProject to update values for Staging/Production

Labels

• Backport needed? -> add the backport label
• Includes a DB migration? -> add the area:migration label

[Pezmc]

The timer mixin is a good way to handle this, though currently a bit complex for our needs, I also note it doesn't have any sort of backing off build in, which I believe we should have by default to reduce the risk of self DDOS, but I can add that down the line, so happy to move forward!

[Steve-Mcl]

though currently a bit complex for our needs

I understand your point however the ugly work to make polling work (and stop working when you leave a page) in vue is just awful & we need a way to simplify this and have a common approach IMO. So while the timer logic (in the mixin) is slightly more complex (internally), implementing timers (on a page) that dont get "left running" and are easy to start/stop on demand outweighs that (I hope).

Are you going to merge or shall I Pez?

[Steve-Mcl]

I also note it doesn't have any sort of backing off build in, which I believe we should have by default to reduce the risk of self DDOS

TBF, neither does the random implementations of setInterval we currently do 🤷

We could add an options with .timeout to the API calls to ensure we poll < timer set interval?

[Pezmc]

@Steve-Mcl There's a best practice setTimeout implementation as part of instance status polling, that was the standard I wanted our codebase to reach (this is admittedly in my head and not documented anywhere). It has backing off, and handles mount/unmount events to start/stop the timer in a succinct way.

We can merge that implementation with this new timer library and have the best of both worlds.