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?

[aantron]

Creating this promise at program init time seems questionable now.

Before, the never promise was a sort of orphan promise in the heap that was fine to have floating around since init time.

But the on_sigterm promise should probably only be created if serve/run are actually called, since a program might end up with Dream linked in but never actually use it. It seems questionable to affect signal handling at init time even if Dream does not end up getting used (or at init time even if Dream does end up getting used).

[yawaramin]

TODO: reconsider approach for multicore.