fix: panic on SIGHUP by closed /dev/tty

[ThomasFrans]

This fixes a panic caused by the SIGHUP signal being sent to the process after its controlling terminal closes. Handling SIGHUP isn't necessary as we're not interested in whether the controlling terminal closed, only in the fact that we need to terminate. SIGTERM will always be sent as well so just react to that.

closes #1282

[ThomasFrans]

This was an interesting one to find. I created a minimal version using just cursive and signal-hook which revealed that a minimal version shows the same behavior of panicking after receiving SIGHUP. I then removed the SIGHUP from the signals to handle and noticed the process still received SIGTERM when the terminal closed. I guess the kernel always sends signals in a specific order and makes sure to send SIGTERM BEFORE /dev/tty is closed, and SIGHUP AFTER /dev/tty is closed. It's a small thing but I didn't know it worked like this. Interesting bug 😄

[hrkfdn]

Does this also happen with the async handling from #1304? I'm wondering if there's some race condition due to duplicate signal handling and whether the way signals are handled (Cursive event loop vs. async task) makes a difference. Would test this myself but can't at the moment, unfortunately.

[ThomasFrans]

You're right. I think the other PR solved the issue and this one isn't necessary. I don't fully understand what is different between the previous approach and the current one with an async task, but if it works it works I guess 😄

I just noticed that there is a bug in the current main branch because I mixed up these two PRs when I was working on them and one SIGHUP went missing in the handle_signals() function at src/application.rs:64,20.