Remove clock from Redux store

[rohanpurohit]

This PR:

• move app backend actions/reducers/selectors to connection
• removed CLOCK_UPDATED action
• removed backendHeartbeat action (only used in HeartbeatBackendListener component)
• removed HeartbeatBackendListener component from OverlayScreen
• naturally removed getClock and getClockTime selectors
• fix the toolbar clock after removing getClock, an useEffect with a interval of 1 sec using new Date()
• fix display tab in settings after removing getClockTime

add temporary saga code to detect backend connection loss.

TODO (ethan/rohan):

• finish saga part for the backend connection (it works! but I'm sure there is a better way to do it) ~fix unit tests after removing getClock~ -~add the ability to dispatch event log for software connectivity loss.~

[rohanpurohit]

I did not really give much thought to my code for saga! it does work but I'm sure there is a better way to do things! @ethanjli maybe you can co-author that part??

Testing:

• performance on chromium process has improved a lot.

[rohanpurohit]

We'll also need to add the heartbeat-related functionality back as a saga

I don't think I completely understood this, just add back what I deleted, or add a generator function that dispatches the action in saga.ts? btw I deleted that thinking even that spams a lot and doesn't look like we are using it anywhere, but I'm guessing we might need it just in case or for future features?

[rohanpurohit]

saw this TODO and moved backend stuff from app to connection

[rohanpurohit]

@ethanjli can you take a look at the latest changes for saga? so basically I'm checking if we have a STATE_UPDATED in a time period of 3 seconds, if we don't have that then we dispatch BACKEND_CONNECTION_DOWN, since we have this I'm assuming we can now remove the BACKEND_HEARTBEAT actions?

[ethanjli]

CPU usage measurements after running the frontend dashboard with the simulator backend on the RPi for at least 10 minutes:

• On develop (85ae493), CPU usage of the chromium process is usually between 90% and 100%, occasionally reaching 85% and rarely reaching 80% or 105%
• On this PR (12dec45), CPU usage of the chromium process is usually between 65% and 75%, often reaching 60%, occasionally reaching 85%, rarely reaching 90% or 55%.

If end-user latency looks good to you, I think this concludes the performance optimization on the frontend for running in the dashboard; in future commits we just need to check against performance regressions. I think it's still worth fixing the issues of massive redraws for the alarm border, modals, etc., in order to improve responsiveness to user actions. Regardless, for HFNC mode we need to fix the issue of the red border flashing on the quickstart screen (and being slow in doing that) when we stop ventilation.

CPU usage in the Python backend server is still very high, and based on what we've seen in this PR I suspect the culprit is that the backend is polling on clock updates (like what we removed with redux + sagas in this PR) every millisecond (!!!). The simple solution would be to accept higher clock jitter, e.g. by polling only every 2 ms or every 5 ms; the more efficient, more accurate, but potentially much more complicated solution, would be to have all timing-related filters (state synchronizers, backend protocol, server protocol) report the next clock updates they need, and then ventserver.integration._trio.process_clock would sleep for variable durations and wake for the deadline of each requested clock update.

[rohanpurohit]

Looks good to me in terms of latency!

1. This project is licensed under Apache License v2.0 for any software, and Solderpad Hardware License v2.1 for any hardware - do you agree that your contributions to this project will be under these licenses, too? Yes.
2. Were any of these contributions also part of work you did for an employer or a client? No.
3. Does this work include, or is it based on, any third-party work which you did not create? No.

[ethanjli]

Moving the connection-specific code from store/controller into store/connection turned into a giant renaming operation because then it also made sense to move the protobuf files (and some associated type definitions) from store/connection/proto to store/proto, so a lot of frontend files have been touched. I've tried to restrain myself by not doing more moving of code or renaming of things beyond that, since those things should really be saved for a future PR. @rohanpurohit Can you try to go to all of the various frontend screens and press all of the various buttons to ensure that the frontend doesn't break (e.g. with console.log errors or with typescript/eslint/etc. complaints in yarn start) on these latest changes? Once it looks good to you, you can go ahead and merge this PR.

[rohanpurohit]

Moving the connection-specific code from store/controller into store/connection turned into a giant renaming operation because then it also made sense to move the protobuf files (and some associated type definitions) from store/connection/proto to store/proto, so a lot of frontend files have been touched. I've tried to restrain myself by not doing more moving of code or renaming of things beyond that, since those things should really be saved for a future PR. @rohanpurohit Can you try to go to all of the various frontend screens and press all of the various buttons to ensure that the frontend doesn't break (e.g. with console.log errors or with typescript/eslint/etc. complaints in yarn start) on these latest changes? Once it looks good to you, you can go ahead and merge this PR.

mostly tried everything! looks good to me. merging