Rust rewrite

[jim3692]

This implementation is meant to be a drop-in replacement of the current bash implementation. All Desktop Audio and monitoring are not implemented, as they will probably be temporarily removed in the next release.

It builds without issues with rustc 1.76.0 and cargo 1.76.0, but some dependencies may fail to build on older versions.

Since some distros still distribute older versions of rustc, it is recommended to use rustup in order to get the latest version of rustc and cargo.

To make the installation easier, I would suggest the distribution of static binaries for x64 and aarch64, but we need to see if static linking is possible with the pipewire crate (instead of manually calling pw-cli and pw-dump).

We need to update the flake.nix before merging this

[IceDBorn]

Should we include the flake changes into this PR as well?

[jim3692]

Should we include the flake changes into this PR as well?

We should probably do it this way, in order to not break anything (hopefully) while migrating

[alansartorio]

Looks good, a few observations:

1. If you prefer using 2 spaces for indentation we should add a rustfmt.toml in the root of the rust project with the following content:

tab_spaces=2

And then run cargo fmt to fix the formatting

2. We should be able to remove the unsafe code used in the pw-dump caching, I can help with that
3. Should we use the debug or the release build? I think the user should be able to cargo clean in the project to free some space without it breaking, but the binary would get deleted. Maybe we want to use cargo install --path . --root ../connector and launch it from there?
4. There are some eprintlns left behind. We should probably use the log crate exclusively. We can also make it log into a file later, as we cant normally see the stdout.

I recommend you use cargo clippy as the "check command" in rust-analyzer to develop rust, it helps to find improvements.

[IceDBorn]

@alansartorio unspecified tabs please

[jim3692]

We should be able to remove the unsafe code used in the pw-dump caching, I can help with that

I do not see any point for further improvements on that, as we will eventually move to the pipewire crate using your branch.

Should we use the debug or the release build? I think the user should be able to cargo clean in the project to free some space without it breaking, but the binary would get deleted. Maybe we want to use cargo install --path . --root ../connector and launch it from there?

I guess, we should indeed use the release build instead.

There are some eprintlns left behind. We should probably use the log crate exclusively. We can also make it log into a file later, as we cant normally see the stdout.

I don't remember where I found those, but the eprintln sends the logs to the log crate.