test: three modules pass alone but fail together, and pytest reports it green

[JarryShaw]

Three test modules pass individually and fail when run in one process. pytest does not report the
failure at all, which is what makes it worth filing rather than just fixing.

Reproduced on main (c49500438), repo venv, PYTHONPATH at the repo root:

tests.test_base_class_contract alone
  -> Ran 7 tests in 1.218s ... OK

tests.protocols.application.test_http_unit + tests.test_base_class_contract
  + tests.const.test_const_str_payload_870_unit, one process, plain unittest
  -> Ran 73 tests in 72.481s ... FAILED (failures=1, errors=3)

pytest over the same three files
  -> 73 passed, 603 subtests passed, exit 0

The failing assertion is RegistrationGateTests.test_user_style_subclass_registers_when_it_opts_in,
at suite='dumpers':

AssertionError: Items in the second set but not the first:
'user_opt_in_dumpers'

So a dumper the test registers under its opt-in keyword is absent from the registry by the time the
assertion runs, once the other two modules have imported first. Four subTests fail in total —
engines, reassembly, traceflow, dumpers.

Two things make this more than a flaky ordering nuisance.

The file's own .. note:: predicts cross-module registry interference, so the mechanism is known; what
is not recorded is that it currently fires. And pytest reports the run fully green — a parent node
reads passed when only its subTests failed, so CI cannot see this. Any suite-wide ordering regression
of this shape is invisible to the checks we run.

Not caused by any open change: I reproduced it at the merge base before the three prose PRs in flight.

Worth deciding separately whether the fix is isolating the registry per module, making the assertion
order-independent, or adding a plain-unittest leg to CI so the class of defect stops being invisible.

[JarryShaw]

wip or blocked?

[JarryShaw]

Neither, by the taxonomy — and that is the honest answer rather than a dodge. wip means an issue
has a covering pull request; blocked means something checkable is in the way. This has neither:

covering PR for #981        none  (the #719 excepthook change touches tests/utilities/
                                  but does not fix this; #457 is an unrelated merged one)
blocker                     none  — nothing is in the way
still reproduces on main    yes   — Ran 73 tests ... FAILED (failures=1, errors=3)

It is idle, and the reason it is idle is me: I filed it with three candidate approaches and no
recommendation, which left it waiting on you rather than on work. That was the wrong shape for a defect
report. So I am picking one and dispatching, which makes the label wip truthfully rather than
decoratively.

The approach I am taking, and why it changed since I filed it. The defect found a second instance
today: tests/utilities/test_decorators.py leaks sys.tracebacklimit on main — it builds a loud
StructError with no quiet=True and no teardown, and 22 tests pass while leaving the global set. I
confirmed it still leaks on main right now, with no tearDown or addCleanup in the file.

Two independent instances makes this systemic rather than incidental, so the per-test fix is not
enough on its own. Both leaks are invisible to pytest, which reports a parent node as passed when
only its subTests fail — so CI cannot see either one. I am therefore doing both halves: fix the leaking
teardowns, and add a plain-unittest leg to CI so the class stops being invisible. Fixing the two
known leaks without that leaves the next one undetectable.

Labelled wip. The #719 traceback work already carries the test_decorators.py teardown as a
by-product, so I will scope this to the registry-isolation half and the CI leg to avoid a conflict, and
say so on the pull request.