collectd: bring back xencpu plugin

[hehongbo]

Xen is no longer in a broken/unmaintained status, so we can bring the xencpu plugin back easily.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• 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/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 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
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[hehongbo]

cc @bjornfor and @NixOS/xen-project

[SigmaSquadron]

I'm worried this may cause a regression w.r.t #148961. There should be a check to remove the Xen plugin if we're not building for x86_64, at least until #345217 is fixed up and merged.

Also, perhaps the module needs to be updated to run with root permissions if Xen is enabled on the same configuration. (I'm assuming nobody will use this in a domU)

[emilazy]

lib.meta.availableOn can be used for availability checks. Enabling functionality in a module should not automatically increase attack surface as root. An assertion or warning is a better idea.

[hehongbo]

Oops... I accidentally deleted the remote branch I'm working on, I'm sorry.