program: exit(0) directly in terminateWithSignal to avoid runtime exit(2)

[aron-muon]

Problem

terminateWithSignal() re-raises the original signal back to the process via signal.Reset() + process.Signal() to mimic a signal-style exit (e.g. 128+SIGTERM=143). But signal.Reset() does not install SIG_DFL, it only disables Go's user-channel routing. The runtime's signal trampoline is still installed and intercepts the raised signal, dispatching it to runtime.dieFromSignal():

raise(sig); osyield x3; setsig(sig, _SIG_DFL); raise(sig); osyield x3; exit(2)

Multi-goroutine programs running as PID 1 in a PID namespace reliably hit the exit(2) fall-through. bb_worker and other daemons exit code 2 on graceful SIGTERM despite a clean shutdown, pods end Failed/Error in k8s. The existing time.Sleep + os.Exit fallback was unreachable code (and time.Sleep(5) is 5 nanoseconds anyway).

Approach

Skip the signal-raise dance and exit with the right code directly. 128+signal is what POSIX shells and init systems derive from WIFSIGNALED, so it's user-visibly equivalent without going near Go's signal machinery.

Per review feedback: exit 128+signal is correct for one-shot tools (bb_copy, sync_jwks_to_configmap) where signal interruption should leave a non-zero status, but wrong for daemons where graceful shutdown should look successful to the supervisor (k8s pod phase Succeeded, systemd inactive (dead) without failure).

Add a variadic Option to RunMain:

• Default, exit 128+signal (correct for one-shot CLI tools)
• program.WithDaemonExit(), exit 0 (correct for long-running daemons)

Migrate this repo's daemons (bb_storage, bb_replicator) in the same PR; leave bb_copy and sync_jwks_to_configmap unchanged. Cross-repo daemons (bb_worker, bb_scheduler, bb_runner in bb-remote-execution; bb_autoscaler elsewhere) pick the daemon variant matching their lifecycle when they bump the dependency.

Refs

• os: Process.Signal on the current PID should signal the current thread  golang/go#19326
• os/signal: Reset doesn't reset ignored signals golang/go#46321

[EdSchouten]

Even though returning 'exit 0' may be acceptable for daemons, program.RunMain() may also be used by one-shot processes like bb_copy and bb_autoscaler. I don't think we want to return an exit code of zero if those are terminated through signal delivery.

[aron-muon]

Even though returning 'exit 0' may be acceptable for daemons, program.RunMain() may also be used by one-shot processes like bb_copy and bb_autoscaler. I don't think we want to return an exit code of zero if those are terminated through signal delivery.

Yeah, makes sense - new approach is in, thoughts on self selecting whether running as daemon vs default one shot process?