Maintaining backend state and updating the frontend

Our current backend <-> frontend communication paradigms can result in disconnects between the frontend(s) and backend, specifically if a client drops or a new client joins midway through some backend operation.

• Field values are updated each packet receipt if the Field is present in the received packet and the value has changed in comparison to the previously cached packet. If a field doesn't update after a client connects they will see N/A and have no info on Limit status. We used to get around this by replaying the last few minutes of telemetry through the browser to "catch the client up" but that has since been removed. The plans to move limit checkout out of the frontend would alleviate part of this issue
• If a long sequence is run and a client disconnects / connects midway through execution they will have no information regarding the current "in execution" state. This means that commanding and sequencing will not be properly disabled and the client will remain out of sync until another event can pull it up to the latest state.
• Scripts suffer from a similar problem as the above. If a client drops / joins midway through script execution there is no way to control / interact with the previously executed script. If you had a script that required user input to stop (via abort or a UI popup) you could potentially end up with no way of stopping it outside of restarting the backend.
• UI notifications (I.e., ui.confirm and the like) toggle a modal via the util.Modal component. Clients that join after the corresponding events that trigger the modal have fired will not see the modal. Similar to the scripts above, if a modal is required for user interaction (E.g., to continue script execution) you could end up needing to reboot the backend to regain control.