fix(docker): deliver SIGTERM to the Ballista processes in the images

[villebro]

Rationale for this change

With this change, containers built from the published images stop the way their Ballista processes expect. Today each entrypoint runs its binary as a child of bash, which stays PID 1 and drops the SIGTERM from docker stop or the kubelet. Executors never drain, and every container waits out its grace period to be SIGKILLed.

Closes #2589.

What changes are included in this PR?

• Entrypoints. The executor, scheduler and CLI entrypoints exec their binary, so it runs as PID 1 and receives SIGTERM, as the result service's entrypoint already does.
• SIGTERM handling in each binary. As PID 1, a process only stops on SIGTERM if it handles the signal itself.
  • The executor already handles it, and drains.
  • The scheduler now exits on SIGTERM or Ctrl-C. It doesn't drain its connections yet (Scheduler graceful shutdown #565).
  • The CLI now exits on SIGTERM, leaving the TUI's raw mode and alternate screen first if it's open. Its REPL writes each history entry as it's added, so the history survives any stop. Ctrl-C stays with the REPL.
  • The scheduler shares the result service's handler, which moves to ballista_core::utils::shutdown_signal. ballista_result_service::shutdown_signal re-exports it.
• Standalone. The entrypoint stops the executor first, so it drains while the scheduler is still up, then stops the scheduler, and passes on the executor's exit status. It waits for the scheduler's port with bash's /dev/tcp, because the image doesn't install nc.
• Compose. The benchmarks container gets init: true for its sleep infinity.
• Docs.
  • The Kubernetes guide notes that two settings cap an executor's drain at 30 seconds by default: the pods' terminationGracePeriodSeconds and the scheduler's --executor-termination-grace-period. Raise both if tasks can run longer.
  • The 56.0.0 upgrade guide describes the new stop behaviour.

Related: #565 (the scheduler now exits on SIGTERM; draining is still to come), #2357 (with #2448, executor pods also drain their Flight streams), #2525.

Are there any user-facing changes?

Yes, all in docs/source/upgrading/56.0.0.md:

• Executors drain their running tasks on SIGTERM.
• The scheduler, standalone and CLI containers stop promptly on SIGTERM.
• Outside the images too: the binaries handle SIGTERM themselves, so deployments that override the entrypoint, for example with a Kubernetes command:, behave the same.

How was this tested?

• shellcheck passes on every changed script.
• The standalone entrypoint's stop logic was exercised with stand-in processes:
  • on SIGTERM, the executor drains before the scheduler stops
  • the executor's exit status is passed on
  • a SIGTERM during startup stops the scheduler cleanly.
• On SIGTERM, the CLI exits with status 143 through its own handler, not the signal's default action, and the lines entered before it are in .history. Normal \q exits across sessions keep each entry once.
• The scheduler's SIGTERM handling wasn't exercised locally, because the sandbox it was developed in blocks port binds. It uses the result service's handler.
• The reproduction in Docker entrypoints swallow SIGTERM, so graceful shutdown never runs in the published images #2589 uses the same ubuntu:26.04 base and entrypoint shape. Without exec, docker stop never reaches the process, which is SIGKILLed (exit 137). With exec, a process that handles SIGTERM gets it and stops straight away.

[andygrove]

Thanks @villebro, and thank you @avantgardnerio for reviewing