Stop server on SIGTERM by default

[yawaramin]

Fix #174

[Willenbrink]

Looks good!

I was wondering if we should also handle SIGQUIT but that already works. See also this discussion for the common signals to terminate processes. SIGHUP might be interesting at some point.

[aantron]

if we should also handle SIGQUIT but that already works

In what context? I have SIGQUIT working in the shell to terminate Dream servers without this PR.

λ dune exec example/1-hello/hello.exe
03.10.25 07:11:33.858                       Running at http://localhost:8080
03.10.25 07:11:33.858                       Type Ctrl+C to stop
^\fish: Job 1, 'dune exec example/1-hello/hello…' terminated by signal SIGQUIT (Quit request from job control with core dump (^\))

But interestingly SIGTERM also also works:

λ dune exec example/1-hello/hello.exe
03.10.25 07:12:58.001                       Running at http://localhost:8080
03.10.25 07:12:58.001                       Type Ctrl+C to stop
^Zfish: Job 1, 'dune exec example/1-hello/hello…' has stopped

λ bg
Send job 1 'dune exec example/1-hello/hello.exe' to background

λ kill %1
λ fish: Job 1, 'dune exec example/1-hello/hello…' terminated by signal SIGTERM (Polite quit request)

This appears to be an issue inside containers. Is SIGQUIT relevant for Dream servers running inside containers?

[yawaramin]

TODO: reconsider approach for multicore.

[Willenbrink]

It's a bit difficult to observe the effects because, when starting Dream from the terminal, it inherits the signal handlers from the shell. But the signal handling doesn't work on master but does on this branch when using e.g.

#!/bin/bash
trap '' SIGTERM SIGINT
setsid dune exec example/1-hello/hello.exe &
PID=$!

I've also added a SIGINT handler because AFAICT this is the default (see e.g. https://go-cookbook.com/snippets/context/graceful-shutdowns)