Reinstate evdev-based key handling

[TTWNO]

• Use generic version of serde_json
• fmt
• Cleanup using macro
• Make mode an exaustive enum
• Update events struct to work like Command does
• Spawn new task for input events
• Update services to handle input events
• Use new input event handlers
• Update cargo lock
• Add input server binary
• Update cargo lock

[TTWNO]

Instructions on testing:

# in Odilia root directory
$ cargo run
# in another terminal, in the input-server/ directory
# your user must be in a group which is allowed to read evdev
$ cargo run

Now press capslock+g to send the "stop speech" command. This should make the TTS say "stop speech, eh!"

[TTWNO]

This is not ready to merge. Still need to work in a way to activate automatically, verify scripts work in CI, and add a config file.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 71 lines in your changes missing coverage. Please review.

Project coverage is 5.94%. Comparing base (fa09dab) to head (b919bca).
Report is 24 commits behind head on main.

Files with missing lines	Patch %	Lines
odilia/src/tower/handlers.rs	0.00%	53 Missing ⚠️
odilia/src/main.rs	0.00%	9 Missing ⚠️
odilia/src/tower/choice.rs	0.00%	6 Missing ⚠️
odilia/src/state.rs	0.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #163       +/-   ##
==========================================
- Coverage   18.90%   5.94%   -12.96%     
==========================================
  Files          20      16        -4     
  Lines         984     757      -227     
==========================================
- Hits          186      45      -141     
+ Misses        798     712       -86     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TTWNO]

All key handling features are implemented and proptested.

Resolved questions:

• Do we run the proptests in CI? Yes!
• Should we start using cargo nextest to run them in parlell? Consider at a later date.

Unresolved questions:

• Do we run the proptests as part of CI code coverage?
  • While it takes an absolutely ridiculous amount of time (even on my desktop, even in release mode) it is valuable information and better shows off how much effort has been made to cover all our bases.
• Should we combine the tests and coverage jobs since they both run the same code?

TODO:

• Auto-spawning from main odilia binary.
• User/group udev rules scripts
  • Tests that this works on CI (probably using docker images?) for a few popular distributions.
• Run proptests as part of CI
• [ ] see if there is a way to not compile zbus for the input daemon. It doesn't need it, but transitively depends on it due to odilia-common which enabled the feature in atspi-common.
  • [ ] If we can do this, run the test in release mode on CI. It won't take that much longer to compile but saves minutes of runtime.
• Fully document w/ doctests. This is a small component with a lot of complexity; it'll be needed by anyone who wants to contribute (including future me).

[albertotirla]

• yes, we should run proptests in CI
• considering how long it takes, perhaps only if the input crate didn't change, unless we want to add property testing for more of odilia in the future
• hmm, proptest in coverage sounds interesting, except I'm not sure this should run the input proptest for every unrelated pr
• yes, using nexttest sounds interesting and we should use it if we can, except from what I know, cargo test already runs tests in paralell

[TTWNO]

yes, we should run proptests in CI

Okay. Good starting point.

considering how long it takes, perhaps only if the input crate didn't change, unless we want to add property testing for more of odilia in the future

We can have a seperate workflow file just for this crate, and filter on if files in the input-server directory change.

hmm, proptest in coverage sounds interesting, except I'm not sure this should run the input proptest for every unrelated pr

There is a way to merge results so we could produce a build artifact whenever the directory is modified and combine future coverage stats with it on invocation. I'm not certain this strategy works across different branches, but it's worth a shot!

Second option is my hosting provider allows renting short-term dedicated hardware w/ a REST API. Technically we could use it as a self-hosted runner. We can just exclude the proptests from the GH runners and then have a +propcheck command for PR comments that sends it off to the big server when we're ready (sort of like how Bors works on Rust's repo)

Third option: is there a way to run a Github action locally and have the results shown in the PR? If there is, then I don't mind doing it for the last step of merging. I'd prefer an automated solution, but manually running a big CI job locally, and having that be enforced is almost as good :)

yes, using nexttest sounds interesting and we should use it if we can, except from what I know, cargo test already runs tests in paralell

It can but usually doesn't unless you enable it with -jN where N is the number of processors. Not sure what the GH machines have so maybe I'll leave that alone for now.

[TTWNO]

cargo cross CI jobs are working!

Can't actually run the tests because I can't get a session bus running. Whenever we figure out how to do that, we can change from command: build to command: test in the ci.yml file :)

[TTWNO]

Well apparently x86 musl still fails... I'll work on it.

[TTWNO]

@albertotirla Ready for second round of reviews!

[TTWNO]

Only didn't use the error!(%error, "...") syntax with the grabbing error, since rdev::GravError doesn't implement Display.