nixos/test-driver: add Machine.record_audio

[Synthetica9]

Motivation for this change

Allows you to record audio from a VM and verify that sound actually played.
Depends on #153866

TODO:

• Write some docs
• Get ALSA driver to work for QEMU? It's so choppy on my machine it's actually interfering with the proper functioning of the machine (cage threw a warning that "my machine is too slow" 😅)

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[Synthetica9]

@ofborg test pulseaudio.user pulseaudio.system firefox mpd

[Synthetica9]

Gonna draft this until #154168 is merged, so that'll probably take some time. If anyone wants this in earlier, let me know.

[tfc]

what do you think about simply enforcing that the user provided a sane filename and throwing a nice self-explaining exception otherwise?

[Synthetica9]

Oh I think something got lost in the rebase, but this is the same logic we use for screenshots. I factored out the function, but didn't use it for screenshot

[tfc]

reading this function feels like there is a lot of qemu-audio-capture specific domain logic and only a little bit of glue code that calls qemu-stuff and then throws it through the domain-specific code.

If you put the domain-specific part into a pure function, you would make it unit-testable and have test cases that at the same time document the interface that you expect from qemu. what do you think, does this make sense in your opinion, or do my ideas result in more work than value?

[Synthetica9]

I feel like it is already pretty testable by calling it in weird conditions (capture already running at the same filename, invalid arguments, "manually" stopping the capture, etc.)