docs(snix/docs/TODO): drop builder TODOs

A mention of these different builders is included in the a footnote
in the documentation, and various issues for the different TODOs were
created:

 - #128 Implement bwrap-based Builder
 - #129 Implement gVisor-based builder
 - #130 Implement Cloud Hypervisor-based builder
 - #131 OCI builder: add preflight checks
 - #132 BuildService: refactor to be more granular

Change-Id: I349b799e233ba8bef39a139cf2453d3214bb69b3
Reviewed-on: https://cl.snix.dev/c/snix/+/30474
Autosubmit: Florian Klink <flokli@flokli.de>
Tested-by: besadii
Reviewed-by: Jonas Chevalier <zimbatm@zimbatm.com>

snix/docs/src/TODO.md

@@ -70,26 +70,6 @@ Extend the other pages in here. Some ideas on what should be tackled:
    is probably still not too clear.
  - Absorb the rest of //snix/website into this.
 
-### Builders
-Once builds are proven to work with real-world builds, and the corner cases
-there are ruled out, adding other types of builders might be interesting.
-
- - bwrap
- - gVisor
- - Cloud Hypervisor (using similar technique as `//snix//boot`).
-
-Long-term, we want to extend traits and gRPC protocol.
-This requires some more designing. Some goals:
-
- - (more granular) control while a build is happening
- - expose more telemetry and logs
-
- - Add pre-flight checks in the OCI builder:
-   - ensure `fusermount` suid binary exists
-   - ensure `allow_other` is set
-   - ensure `runc` exists in `$PATH`
-
-
 ### Store composition
  - Combinators: list-by-priority, first-come-first-serve, cache
  - Store composition hierarchies (@yuka).

web/content/docs/components/build/protocol.md

@@ -20,10 +20,10 @@ These are only separated by [compiler preprocessor macros][ifdef] within the sam
 source files despite having very little in common with each other.
 
 In Snix, the Builders need to implement a trait, and there are multiple
-implementations. In addition to an [OCI][] builder[^k8s], we also include a gRPC
+implementations. In addition to an [OCI][] builder and plans for
-client (and server adapter), allowing to run the builder both locally or
+more[^other-builders], we currently include a gRPC client (and server adapter),
-remotely, or plug in your entirely separate Builder, as long as it speaks the
+allowing to run the builder both locally or remotely, or plug in your entirely
-same gRPC protocol.
+separate Builder, as long as it speaks the same gRPC protocol.
 
 Check `build/protos/build.proto` for a detailed description of the protocol,
 individual fields, and the tests in `glue/src/tvix_build.rs` for some examples.
@@ -96,8 +96,9 @@ regarding [Build Provenance][slsa-provenance].
 [frankenbuilds]:   https://blog.layus.be/posts/2021-06-25-frankenbuilds.html
 [slsa-provenance]: https://slsa.dev/spec/v1.0/provenance
 
-[^k8s]: With a well-defined builder abstraction, it's also easy to imagine
+[^other-builders]: With a well-defined builder abstraction, it's also easy to imagine
-  other backends such as a Kubernetes-based one in the future.
+                   other backends such as a Kubernetes-based / bwrap / gVisor /
+                   Cloud Hypervisor in the future.
 [^reapi]: There have already been some discussions in the Nix community, to switch
   to REAPI:
   https://discourse.nixos.org/t/a-proposal-for-replacing-the-nix-worker-protocol/20926/22