fix(python): Shut workers down without raising from signal handlers

[untitaker]

Reland of #764 (reverted in e9d1494). See that PR for the original
investigation into the KeyboardInterrupt-from-a-signal-handler crashes; the
approach here is unchanged. What follows is only what is new.

Why it was reverted

One inverted boolean:

if server.wait_for_termination(timeout=SHUTDOWN_POLL_INTERVAL_SEC):
    break

grpc returns True when the timeout elapsed (server healthy) and False once
it terminated — the inverse of Event.wait(), despite the docstring
(grpc/_common.py:161-164). So healthy workers left the loop after one 0.5s
poll and exited 0: clean, no traceback, half a second after warmup. Push mode
is the production default. Now read the right way round, plus a log line when
the server dies unasked.

Every other exit path from start() was checked: the early returns all require
the shutdown bool, and exceptions exit non-zero. This was the only
spontaneous-exit vector.

Why CI missed it

test_push_start_exits_cleanly_on_sigterm fired SIGTERM from the first poll,
so the loop exited after one iteration whichever way the condition was read.
Verified by reintroducing the bug: one test failed, one hung, this one passed.
Fixed by signalling on the third poll, so surviving to it proves the condition
runs; all three now fail fast.

Caveat: these tests mock wait_for_termination, so they prove the loop matches
our belief about grpc's contract, not the contract itself. I checked that
against a real server by hand.

Other changes from review

• fetch_task() re-checks the flag after the RPC and drops the activation.
  This does not speed up shutdown; it stops us claiming a task we won't run,
  which would otherwise sit until it expires on the broker. Metric:
  taskworker.worker.fetch_task.dropped_during_shutdown.
• An earlier revision here dropped wait_for_termination entirely and slept on
  ShutdownSignal.wait(). Immune to the inversion, but it lost detection of a
  server that failed on its own, leaving the parent alive with a green health
  check.

Known regression: pull-worker shutdown latency

stub.GetTask() (client.py:415) has no deadline. cygrpc turns a
KeyboardInterrupt raised from a handler into RPC cancellation, so the old code
aborted an in-flight GetTask immediately. Flipping a bool does not, so the
worker now stays in that call until it returns. Normally that is 20-50ms and
irrelevant, but on a hung connection it means ignoring SIGTERM until k8s
SIGKILLs the pod. The fetch_task re-check above limits the damage (we drop the
task rather than run it) but not the delay. Fixing it properly means putting a
deadline on the RPC — follow-up below.

Follow-ups (not in this PR)

• Deadline on GetTask and on the client's all-hosts-unavailable
  time.sleep(), per the regression above. This is the one that keeps
  pull-worker shutdown from being fully solved.
• The child's SIGTERM handler calls threading.Event.set()
  (workerchild.py:207), which is exactly what this PR's ShutdownSignal
  docstring says is unsafe from a handler. Latent rather than live: children are
  spawned, not forked (--process-type defaults to spawn and nothing
  overrides it), so the child installs that handler as part of its own startup
  and there is no inherited-handler window. Still worth making the two sides
  consistent.
• Unexpected server termination returns 0, so it looks identical to a clean
  SIGTERM to anything watching exit codes. Arguably should be non-zero.
• A second SIGTERM is now inert — the bool is already set, so a hung drain
  can only be escaped with SIGKILL. Fine under k8s, annoying for local Ctrl-C.
• No test drives a real grpc.server(). The serve-loop tests still encode
  grpc's semantics in a mock, now the correct way round.

ref STREAM-1649

[linear-code]

STREAM-1649