Build capability interface

[roberth]

Is your feature request related to a problem? Please describe.

Scheduling a derivation involves a comparison between a derivation's scheduling attributes (such as system and requiredFeatures), and the related properties of a "builder" (such as system, extra-platforms, supportedFeatures, mandatoryFeatures).

In #9899 I have done some exploratory coding to work out these concepts a little better.

Problems:

• "builder" is overloaded. It occurs in the derivation builder attribute, as well as "remote builder", which have very different meanings, yet interact too closely.
• the remote builder configuration is denormalized, which users don't expect, resulting in inaccurate remote builder configs
  • specifically, remote builders and build capabilities are in a one to many relationship
  • by denormalizing the config (repeating the remote builder connection part), connection reuse becomes less efficient
• we don't have a good interface to stub out builds in unit tests
  • this leads to more configuration than desired (#10562)
  • unit test performance is slightly worse, for having to perform an actual build (an easily bearable cost, considering our current over-reliance on functional tests)
• we don't have an interface to separate the store component from the builder component, whether that's an internal or IPC interface
  • local and remote builds feel like chaotic reimplementations of each other because we lack the clarity of such an interface
  • nix-daemon has to manage builds instead of just a store and a build capability trust relation

Describe the solution you'd like

1. Define unambiguous terminology
   • I've renamed "builder" to "build capability" but maybe someone has a better term?
   • We should probably further distinguish between "build capability" and the concrete service or implementation that fulfills that capability, because these are again in a many to many relation.
2. Define interface in C++.
3. Define an IPC interface between nix-daemon and build process or build daemon (or whatever we want to call it).

Describe alternatives you've considered

Additional context

Efforts/ideas to add more "systems" which may or may not be the native system.

• 2759

• https://github.com/NixOS/nix/pull/9968
• ...

Priorities

Add :+1: to issues you find important.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-04-22-nix-team-meeting-minutes-140/44016/1