Improve exit status

[droe]

This pull request is meant to address #252 in the following ways:

• sslsplit will now propagate the privsep child process' exit status to the parent process
• exit status will now be 0 for regular shutdown via SIGINT or SIGTERM
• exit status will now be 128 + signal number if we shut down after catching a different signal that we consider a non-regular shutdown (currently only SIGHUP and SIGQUIT)
• exit status 1..127 are used for error conditions such as config errors or runtime errors; currently exit status 1 is used for all errors but we could change that in the future to e.g. differentiate fatal config errors from runtime errors

Signals that are non-fatal, such as SIGUSR1, will not lead to a shutdown. Some signals not handled by sslsplit, such as SIGKILL or SIGSEGV, will lead to a termination by the kernel, meaning that the process interested in the exit status will use wait(2) to acquire the signal. In the special case of sslsplit running directly from a shell, most shells will translate the signal number to an exit status using the same scheme of 128 + signal number.

All of this is only relevant when not running sslsplit as a daemon.

[sonertari]

If I kill sslsplit with SIGINT or SIGTERM signals, it exits with status 1 (e.g. echo $?). But the second bullet claims that 0 should be returned. Is this expected? I guess I am missing something.

[droe]

You're not missing anything, I broke my change during refactoring. Fixed.

[sonertari]

Appendix E. Exit Codes With Special Meanings reads "Control-C is fatal error signal 2", so I guess they expect us to return 130 upon SIGINT. But I like it this way. As you wish.

[droe]

Thank you, Soner!