Cleanup when terminated by signal

[lifning]

Rel. oxidecomputer/oxide.rs#536

• Catch termination signals (HUP, INT, PIPE, QUIT, TERM on Unixlikes, CTRL-* on Windows¹) and exit cleanly, restoring the previous termcap state in RawModeGuard's drop as when exiting normally.
• If terminfo is available, emit ANSI escape sequence to return from alternate buffer as well.

Footnotes

1. which sure are a pain in the neck to send to an arbitrary PID compared to Unix! ↩

[ahl]

lgtm

[ahl]

can we test windows?

[lifning]

Good question! The hassle wasn't worth it to tokio, who just tests that their own plumbing is working and trusts that Win32 is going to do the right thing: https://github.com/tokio-rs/tokio/blob/d51f16855bce90c3c73ae199c7d6bdb340297e99/tokio/src/signal/windows/sys.rs#L159-L164 (in our case, testing the code paths on Unix is a similar test of our own plumbing)

However, if we're using tokio's signal-handling but not testing Windows, and tokio's implementing the signal-handling but not testing Windows, then who's flying the plane? So to answer the question of "can we test windows," I do believe such a thing is within the realm of possibility: https://learn.microsoft.com/en-us/windows/console/generateconsolectrlevent exists, but unless we somehow put the unit test into its own process group, this would send the event to every process sharing the console -- including the test runner itself, despite the test case itself passing: https://github.com/oxidecomputer/thouart/actions/runs/8369557404/job/22915498686#step:6:71

cargo-test doesn't seem to set a process group for its invocation of the test binary. But nextest has this TODO that should be pretty straightforward to fill in, so I think I'll pursue that route: nextest-rs/nextest@main...lifning:nextest:win32-process-group (as luck would have it, we happen to know the maintainer)

[ahl]

"Let's fire up a windows VM and see if it works lol lmao" is fine by me. We've probably sufficiently stared into this abyss.