htsserver never returns from main(), it blocks on its own exit wait

[xroche]

htsserver does not return from main(). It reaches its exit wait and blocks there, and has done since 2014.

background_threads counted two unrelated things: the --ppid pinger, which only ever leaves through exit(), and each mirror thread, which does return. main() waited on background_threads - 1. With no pinger that is htsthread_wait_n(-1), a negative number of outstanding threads the counter can never reach; with a pinger it is htsthread_wait_n(0), which waits on the pinger itself. Both hang, 10 runs out of 10.

So the counter now holds only what never returns, and each wait names what it must leave running: the pinger for main(), the pinger plus itself for the mirror thread. Just dropping the - 1 is not enough, which is how I had it first. Since background_threads also counted the joinable mirror threads it equalled the live count exactly, so main() would have sailed past the wait while a mirror was still crawling and torn down under it. Review caught that one. Not counting mirrors at all is what makes both call sites correct, and it also closes a latent under-wait inside back_launch_cmd(), where two sequential mirrors left the counter excluding one thread too many and the engine-thread drain got skipped.

Measured with an html root that has no lang.def, so the server fails right after announcing and main() reaches the wait on its own: 10/10 hangs on master with and without --ppid, 0/10 with the fix. The regression case lives in tests/65_port-siblings.test, which already drives htsserver. It fails on master with exited 124, want 1. It asserts the exact status rather than "not a timeout" because a crash or an assertf abort also escapes the wait and would otherwise read as a pass. What it cannot reach from a shell is the case where a mirror is still running at exit, so that leg rests on the review's per-case reading, not on a test.

Worth noting that #752 made this worse rather than caused it. Counting a thread from the moment it is spawned closed the window the pinger used to slip through, taking the --ppid case from an intermittent hang to a certain one.

Closes #753

[xroche]

Noting a second defect this PR closes, so it does not get lost if the fix is reshaped.

The counter is genuinely raced on master. webhttrack_main() increments background_threads at htsweb.c:385, right after creating the mirror thread at :384, and that mirror thread reads the same variable at :427. The write lands after the reader already exists, with no lock and nothing else ordering them, so it is an unsynchronised concurrent access to a plain int. Benign on the platforms we build for, but a data race by the memory model.

This PR removes it instead of papering over it. Afterwards there is exactly one write, at :304 on main's thread before help_server() runs, and two reads: :314 on main's own thread, and :430 on the mirror thread, which main creates later. Thread creation supplies the happens-before, so the counter is write-once-before-spawn and needs no lock. What keeps it safe is that no write happens after any thread that reads it has been created, so putting a per-mirror increment back would bring the race back with it.