feat: alert notification via websocket

[blenzi]

This PR adds support for notifying clients such as pyro-platform instances of new alerts via websocket. Previously the platform had to periodically ping the API to ask if new alerts were sent.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 82.35294% with 6 lines in your changes missing coverage. Please review.

Project coverage is 95.22%. Comparing base (eb4fcc1) to head (896f1f1). Report is 92 commits behind head on main.

Files with missing lines	Patch %	Lines
src/app/api/deps.py	25.00%	6 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #235      +/-   ##
==========================================
+ Coverage   95.04%   95.22%   +0.18%     
==========================================
  Files          60       61       +1     
  Lines        1393     1425      +32     
==========================================
+ Hits         1324     1357      +33     
+ Misses         69       68       -1     

Flag	Coverage Δ
client	100.00% <ø> (ø)
unittests	94.97% <82.35%> (+0.19%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[blenzi]

Websockets have many differences and subtleties with respect to HTTP routes. Without being able to test the setup locally, due to #217, #231, the development is quite hard.

The feature is implemented in a simple setup consisting of an API passing messages received via HTTP to websocket clients and a dash application (code) that receives those messages via websocket. Demo below.

The alternatives I see to move forward:

1. Accept the PR basically as it is with the websocket route unprotected, meaning any one can listen to the alerts (but not posting, like before). This allows implementing the feature in pyro-platform as soon as it is deployed
2. Wait for #217, #231 to be able to test the setup locally
3. Port the security implementation to the test-API above, which can be long and maybe never exactly like this API so back to 1. or 2.

Any suggestions? @frgfm ?

[frgfm]

Before diving into a review, and iterating on this, I want to address something here:

• if in our stack, there is something that is critical to the whole workflow, it's the API. So we have to be quite careful about that
• now here, I understand that the websocket could help the platform reduce its ping on the API. If that's the case, we need to investigate. But then, I suggest making sure that could work, by running the API & the platform locally to make sure that works
• if that doesn't, let's avoid adding a new feature :)

[frgfm]

Closing this since we've moved to the new datamodel, but we might want to reexplore this once we have better webhook reception capabilities on the frontend side. Thanks!