feat: add configurable worker_count for KBS HTTP server

The KBS uses actix-web, which defaults to one HTTP worker thread per
logical CPU core (std::thread::available_parallelism). On high-core-
count systems (e.g., 160-core AMD EPYC 9845 with 320 threads), this
creates hundreds of workers that exceed the container's default nofile
ulimit (1024/2048 in CRI-O), causing the KBS to crash on startup with
"Too many open files".

Add an optional kbs.workerCount Helm value that maps to the
worker_count field in the KBS [http_server] config section. When set,
the KBS uses the specified number of workers instead of auto-detecting.
When unset, the existing behavior is preserved.

The KBS binary already supports worker_count in its config
(kbs/src/config.rs:41, kbs/src/api_server.rs:145-147 in openshift/
trustee v1.1.0) but the Helm chart did not expose it.

Signed-off-by: Jens Freimann <jfreiman@redhat.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: jensfr

templates/kbs-config-map.yaml

@@ -9,6 +9,9 @@ data:
   kbs-config.toml: |
     [http_server]
     sockets = ["0.0.0.0:8080"]
+    {{- if .Values.kbs.workerCount }}
+    worker_count = {{ .Values.kbs.workerCount }}
+    {{- end }}
     insecure_http = false
     private_key = "/etc/https-key/tls.key"
     certificate = "/etc/https-cert/tls.crt"

values.yaml

@@ -48,6 +48,13 @@ kbs:
   # exist in the trustee-operator-system namespace.
   extraSecrets: []
 
+  # Number of HTTP worker threads for the KBS server.
+  # If unset, the KBS binary defaults to one worker per logical CPU core,
+  # which can cause "too many open files" crashes on high-core-count systems
+  # where the container's nofile ulimit is lower than the worker count.
+  # Set this to a reasonable value (e.g., 4-8) on systems with many cores.
+  # workerCount: 4
+
   # NVIDIA GPU confidential computing configuration
   gpu:
     enabled: false