fix(vpn/ipsec): bound shutdown when charon-nm ignores SIGTERM

[sofianebeloucif]

Summary

Fixes #205. A hung charon-nm process (strongSwan's NetworkManager
IPsec plugin) can block system shutdown/reboot for a long time.

charon-nm does not always handle SIGTERM correctly, in particular
when a VPN connection attempt hasn't fully completed. When that
happens it keeps running inside NetworkManager's cgroup even after
NetworkManager.service itself reports as stopped (its Type=dbus
completion condition -- losing its D-Bus name -- doesn't require its
whole cgroup to be empty).

Setting NetworkManager.service's own TimeoutStopSec is not
enough on its own: since the unit is already considered stopped as
soon as its main process exits, that per-unit timer never gets a
chance to force-kill the leftover charon-nm. What actually hangs
shutdown/reboot is a different, later mechanism: once every unit has
been stopped, systemd's low-level systemd-shutdown does one final
SIGTERM-then-SIGKILL sweep over any processes still around, and the
wait before that SIGKILL is governed by DefaultTimeoutStopSec
(system-wide default: 90s), not any per-unit TimeoutStopSec.

This PR bounds both:

• keeps NetworkManager.service's own TimeoutStopSec (bounds
  systemctl stop NetworkManager.service in isolation, documents
  intent);
• lowers the system-wide DefaultTimeoutStopSec, which is what
  actually bounds the real-world hang.

Testing

Added tests/vpn-ipsec-shutdown.nix, a NixOS VM test that:

1. asserts the mitigation is applied (TimeoutStopUSec on
   NetworkManager.service and the system-wide default are both
   10s);
2. simulates a charon-nm process stuck ignoring SIGTERM inside
   NetworkManager's cgroup;
3. triggers a real machine shutdown and asserts it completes well
   within the fixed timeout, instead of hanging for the default 90s.

Verified locally: shutdown takes ~23s with the fix, vs. ~103s with
only the per-unit TimeoutStopSec (no system-wide default), vs.
hanging on the default 90s+ with neither.

Note: I used Claude Code to help write this PR description and comments.

[rlahfa-dinum]

Is there a reason why you closed #249 which contained the disclosure that you used Claude Code to generate the PR?

[sofianebeloucif]

I used Claude Code to help write the PR description and comments for this. I hesitated to mention it because I was worried it would make people take the work behind it less seriously. Closing #249 was me acting on that worry, not a good call in hindsight. Looking through the repo's history afterward (e.g. #234, #235), disclosed Claude Code usage clearly hasn't been a problem here. Reopened cleanly as #250, disclosed. Sorry for the noise.

[jdauphant-dinum]

You can use AI but you have to read, understand and review it.

[rlahfa-dinum]

Why don't we have resources to fix strongSwan itself, wouldn't it be better to fix this upstream or have an issue reference to the bug?

[rlahfa-dinum]

This change has a way more invasive consequence, what justify to bound shutdown/reboot just for the sake of charon-nm shutdown, especially if there might be workloads that requires the natural shutdown/reboot timeouts that could lose data otherwise?

[rlahfa-dinum]

This is a mock test, wouldn't it be better to reproduce the actual strongSwan hung in this test and use it for upstream? I don't think this tests interesting things otherwise.

[rlahfa-dinum]

I believe you intended to be copyright owner as you authored the file