ci: don't use the default problems handler in ci

[jopejoe1]

This makes it possible to use a custom broken massage or to mark a package as slated for removal without triggering the CI.

closes #523712

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.
• Follows the automation/AI policy.

[MattSturgeon]

1. This "adds" 4418 packages that were previously not considered by CI's eval. Presumably due to things like meta.broken?
2. Addressing this only in Nixpkgs CI may not be enough. IIUC, we also need to update hydra, else meta.problems will be a channel blocker.
3. How do we decide which "problems" should and shouldn't show up in CI? Currently this assumes no problems should be seen by CI, however it's CI's job to find issues introduced by PRs; e.g. introducing a package that depends on something with "problems" might be something we want CI to detect.

Review dismissed automatically

[jopejoe1]

1. This "adds" 4418 packages that were previously not considered by CI's eval. Presumably due to things like meta.broken?

Missed the conditional for when we don't want to include broken packages in ci.

2. Addressing this only in Nixpkgs CI may not be enough. IIUC, we also need to update hydra, else meta.problems will be a channel blocker.

I don't see how unfree packages and broken packages and others don't block the channel either, so how would this be any diffrent?

3. How do we decide which "problems" should and shouldn't show up in CI? Currently this assumes no problems should be seen by CI, however it's CI's job to find issues introduced by PRs; e.g. introducing a package that depends on something with "problems" might be something we want CI to detect.

If we want problem to be detected by ci we should add them like i did with broken here but unconditionally.

[infinisil]

Blocking until we know what we actually want, let's discuss in #523712

[MattSturgeon]

This was superseeded by #533376