test_egress_stress leaves its python3 HTTP server running after a failed run #1065

tests/test_egress_stress.rs starts its host HTTP server as a child process (start_http_server: python3 -m http.server <port> --bind ::) and stops it with one kill() in stop_http_server, called after the test's assertions.

Two ways that server outlives the test:

• An early return or a panic skips the stop. The call sits after the assertions, so a failing run never reaches it.
• On a host where python3 is a launcher that runs the interpreter as its child, kill() signals the launcher only and the interpreter keeps listening. A parent-death signal on the launcher does not reach the interpreter either: measured, the launcher dies and the interpreter is reparented to PID 1. Killing the launcher's process group does stop both, but only while the test can still run code.

test_ipv6_egress_to_host had the same shape and left one server per failed try; #1064 moves its server into the test process (LocalTestServer in tests/common/mod.rs), which test_egress.rs and test_proxy.rs already use. The stress test should do the same, so nothing is left to reap on any path.

A test for it can follow host_http_server_stops_when_its_test_returns_early from #1064: start the server through the function the VM test uses inside a body that fails before its cleanup, then require the port to be free.

Not run: the stress test itself on a host with a launcher python3. The leak is from reading the code and from the measurement made for #1064.