Implement adjustment of system time from the backend

[ethanjli]

This PR:

• Implements backend functionality for changing the RPi's system time when it receives an update to the SystemSettingsRequest protobuf message from the frontend.
• Records system time changes in the event log
• Uses monotonic_time (from Python's time.monotonic()) for any timestamps needed to for durations/timeouts/intervals in the backend. Renames most time/current_time parameters in the backend to wall_time (as in the wall-clock time which is kept by the RPi and its RTC), to make it distinct from monotonic_time
• Adds the SystemSettings protobuf message type as the response message for SystemSettingsRequest, which already existed (but was named SystemSettingRequest)
• Improves the layout of the stdout console logs by:
  • Color-coding errors and warnings
  • Making a fixed column-based layout for the fields of the log records
  • Abbreviating (and, when necessary, left-truncating) the names of modules
  • Adding providing line numbers for non-info logging statements (i.e. critical, error, warning, and debug)
  • Providing more information in exception tracebacks about the values of variables
• Improves the comprehensiveness of backend log messages related to connection and loss-of-connection events
• Fixes issues with the display of the current date in the frontend's Settings page (this is the display on the left column, separate from the ValueSpinners)
• Adds some TODOs about future changes needed for frontend/src/modules/settings/containers/DisplayTab.tsx, frontend/src/store/proto/frontend_pb.ts, and frontend/src/store/proto/mcu_pb.ts, and some other places too
• Fixes a subtle race condition resulting from a bug which invalidated my attempts to initialize the wall clock time in the simulator backend's simulated log receiver with the current time rather than time 0 (which was causing some log records in the Event Log to show up as occurring in the year 2073)

This PR also does some refactoring of the backend:

• A bunch of long class names in the backend are shortened, for more uniformity and shorter logging names (this is the reason so many files are changed in this PR)
• Some shared code between ventserver.application and ventserver.simulator is unified into functions defined in ventserver.application.
• The input and output methods of the filters for ventserver.protocols.backend.backend and ventserver.protocols.backend.server, and deletion of ventserver.protocols.backend.SendFilter which doesn't seem to be useful for our backend.
• Moving kill_process into ventserver.io.trio.processes, which is a new file for all sorts of (simple) subprocesses our backend will spawn.

Things to be aware of:

• This PR adds better_exceptions as a package dependency, so you will need to run poetry install again for anything to be able to run.
• ventserver.simulator tries to use zenity to show a popup at the start of the program warning you that you're running the simulator rather than the application. If you don't see this popup, you should install zenity. If you don't have zenity installed, the program will simply log its failure to open the dialog box but otherwise continue as normal.
• On the RPi, before changing the system time you'll have to disable wifi; otherwise, the RPi will immediately overwrite your changes with the time from the internet.
• On the RPi, in order for the backend to be able to change system time, you'll need to run sudo /home/pi/.poetry/bin/poetry run python3 -m ventserver.simulator. Before this works, you'll first need to run sudo /home/pi/.poetry/bin/poetry install.

@rohanpurohit If you're able to make sure you can run everything and change the system time on your RPi, that would be helpful. Since this PR did a big rename and also some refactoring of important parts of the backend, it'd be helpful if you could also test the backend to look for any possible issues with responsiveness or timing. I will perform an end-to-end test of whether everything works with a complete RPi deployment installation and a hardware RTC (so far I've just probed the state of the system using the timedatectl status command and looking at the time in the frontend after doing an "Apply Changes" on the frontend's settings screen).

[ethanjli]

I've changed the backend and deployment scripts to try to run the date command using sudo, because it turns out that the pufferfish_backentd.service is configured to run in systemd as the pi user rather than root.

I've also been encountering some issues with the deployment scripts which require some workarounds and should be fixed in future PRs:

• If I just run deploy.sh without lock.sh, the pufferfish_backend and kiosk services don't start because they depend on tampering.service which is only provided by running lock.sh. It would be better if deploy.sh provided a dummy tampering.service which never fails (so that the other services can proceed), and then lock.sh provided the "real" tampering.service which actually checks file integrity.
• It looks like the pufferfish_backend.service is trying to have its protobuf messages be written to the filesystem at /ventserver/statestore/, which it doesn't have file permissions for, rather than /home/pi/pufferfish-software/backend/ventserver/statestore. Ultimately we will want to write those messages to a separate USB drive, but in the meantime I've added commits to change the working directory of the systemd service to what the backend expects (commits af1c627 - a004ce4).
• For some reason the media-pi-LOGS.mount systemd unit isn't working, even though I have a USB drive named "LOGS" plugged in to the RPi at boot.

[rohanpurohit]

Observations from testing:

• I was able to successfully update the RPI system time from the frontend.
• I did light testing and did not find any regressions from this PR in terms of responsiveness or timing.

on my wsl windows when i tried to run this branch without zenity:

If you don't have zenity installed, the program will simply log its failure to open the dialog box but otherwise continue as normal.

it did not continue as normal and infact terminated with failure: FileNotFoundError: [Errno 2] No such file or directory: 'zenity': 'zenity'

installing zenity on my wsl seems to have a lot of unmet dependencies, for now, I'll just use it by removing await processes.make_dialog

[ethanjli]

it did not continue as normal and infact terminated with failure: FileNotFoundError: [Errno 2] No such file or directory: 'zenity': 'zenity'

Oops, I hadn't tested that error-handling behavior! I've fixed it and tested it on my own system now (running Ubuntu, with Zenity uninstalled).

[ethanjli]

For records-keeping:

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