ci: run the suite under ASan/UBSan and TSan

[benaliabderrahmane]

Description

Runs the existing suite under sanitizers. Two jobs, because ASan and TSan cannot be
linked into the same binary and so cannot share a build tree:

• sanitize (address,undefined) — ASan + UBSan
• sanitize (thread) — TSan

Build-and-test can only fail on behavior a test asserts. The bugs this codebase
actually produces are the other kind: the registry is a lock-free seqlock over
shared memory, delivery is a level-triggered epoll whose git history is largely a
series of lost-wakeup fixes, and endpoint pointers are handed between a dispatch
loop and whatever thread is destroying an endpoint. A missing fence, a
use-after-free on a destroy path, or an unsigned overflow in a timeout
accumulation are all invisible to a green suite and all visible to a sanitizer.

Is this user-facing behavior change?

No. CI configuration only; no source, build or packaging change. Nothing shipped is
built with sanitizers. The diff is two new files: .github/workflows/sanitizers.yml
and .github/tsan.supp.

How was this tested?

This PR is its own test, and the TSan job is red — on a real, pre-existing
bug in devel. That is the workflow working, not the workflow being broken.

sanitize (address,undefined) — pass.
sanitize (thread) — fail, on test_registry_concurrent:

WARNING: ThreadSanitizer: data race
  Write of size 4 by thread T2:
    write_slot_payload   registry.cpp:235   <- slot->pid = entry.pid
      try_add_once       registry.cpp:267
      registry_add       registry.cpp:299
  Previous write of size 4 by thread T1:
    teardown_slot        registry.cpp:319
      registry_remove    registry.cpp:365

A write-write race on a slot payload: registry_remove CASes state to
ENTRY_EMPTY before teardown_slot zeroes the payload, so a concurrent
try_add_once can claim the slot in that gap and both threads write it at once.
The seqlock does not help — it serializes readers against a writer, not two
writers against each other. Reproduced locally on jazzy, the writer side came
in two pairings: write_slot_payload against teardown_slot, and teardown_slot
against itself.

This is already diagnosed and fixed on an unmerged branch,
fix/registry-teardown-before-slot-release (a05ba3f, "erase a removed slot's
payload before publishing it EMPTY"). That commit message documents the two
user-visible manifestations — a corrupted ENTRY_NODE that makes every graph
query in the process fail, and a corrupted ENTRY_SUBSCRIPTION whose zeroed
socket_path silently drops the endpoint from every publisher's send list.

That one stack is not the whole picture, though. halt_on_error=1 stops the run
at its first report, so the job shows one race and exits; fixing that one would
simply expose the next. Measured on test_registry_concurrent with the
suppression removed: 27 reports and 10 snapshot_slot frames — the reader
side. TSan has no seqlock model. snapshot_slot copies a slot's payload with
plain, unsynchronised loads and validates the copy against an atomic sequence
counter, retrying if the writer touched the slot meanwhile; that torn read is the
design, and the comment above the function says so, but TSan reports every
reader/writer pair it sees. .github/tsan.supp — one entry, race:snapshot_slot
— silences the reader side only: 18 reports and 0 snapshot_slot frames with
it, and the genuine writer-vs-writer pair (write_slot_payload against
teardown_slot, which a seqlock does not permit) still fully reported. An earlier
revision of this PR said that if reader-side reports ever surfaced, a documented
suppressions file was the right answer rather than loosening the job; they
surfaced, and this is that file. The suppression is what makes the remaining
redness mean something.

sanitize (address,undefined) was additionally verified locally against this
branch's sources using the exact flag string and option set the workflow exports:
every test binary clean.

Did you use Generative AI?

Additional Information

Four details that are the actual content of this PR, rather than boilerplate:

• -fno-sanitize-recover=all is the point of the ASan job. UBSan's default is
  to print the diagnostic and keep going, so the test still passes and the finding
  scrolls past in a log nobody reads. With this flag, undefined behavior aborts and
  the job fails.
• .github/tsan.supp suppresses the seqlock reader, and nothing else. Every
  entry in that file is a place TSan cannot see the synchronisation, not a place we
  have decided to tolerate a race — which is why it has exactly one line of content.
  Two threads writing the same slot at once is a genuine bug a seqlock does not
  permit, and those reports are deliberately left visible. Keeping the file this
  short is the whole judgment: it is the difference between a job that is red for
  one stated reason and a job that is red for an unreadable mix of them.
• detect_leaks is left on, but it covers less than this PR first claimed.
  LeakSanitizer tracks heap allocations and nothing else: a program that leaks an
  epoll fd and an eventfd and detaches a thread that never joins exits 0 under
  it, while an unreachable heap allocation exits 1 — both checked against controls
  on the same toolchain. So it does not prove a background thread is joined or its
  descriptors closed. Descriptor and thread lifetime need explicit test coverage,
  and the workflow comment now says so rather than naming tests: the ones that
  would cover it live in test_rmw_listener_callbacks.cpp, which the
  listener-callback stack adds and which does not exist on devel, this branch's
  base. detect_leaks remains the most likely source of
  third-party noise; if a ROS dependency leaks, the fix is a suppressions file
  rather than turning the check off — a precedent this PR now sets.
• TSan runs with halt_on_error=1, second_deadlock_stack=1 and
  suppressions=.github/tsan.supp. The first makes a race fail the job instead of
  being counted and ignored, and — as above — ends the run there. The second only
  widens a report rather than enabling anything: libtsan has deadlock detection on
  by default, and the flag makes a lock-order inversion name both lock sites instead
  of one, verified against a lock-order-inversion control. The lock order it reports
  on is real — the callback setters take callback_mutex then queue_mutex, and
  getting that pair out of order deadlocks.

Two workarounds, not preferences — one a container setting, one a step that runs
inside it. --shm-size=1g, because the default Docker /dev/shm is 64MB while one
domain registry mmap is ~37MB that rmw_shutdown never shm_unlinks, so tests
that init multiple domains across processes exhaust the tmpfs and die with
SIGBUS. And sysctl -w vm.mmap_rnd_bits=28, because Ubuntu 24.04 raised ASLR
entropy past what the ASan and TSan shadow mappings can accommodate ("unexpected
memory mapping" before main() runs); it fails soft, because an unprivileged
container cannot write sysctls at all and the runner image may not need it.

One distro, not the four-distro matrix: these findings are properties of our own
sources. Adding a distro axis is a two-line change if it ever earns the cost.

Merge order. This touches only .github/, so it conflicts with
nothing — but it cannot go green until the registry race is fixed, and a05ba3f
does not cherry-pick cleanly onto current devel (registry.cpp, registry.hpp,
DESIGN.md and test_registry_concurrent.cpp all conflict; it predates the
doorbell and TL-pull work). Three
ways forward, in the order I would pick them:

1. Rebase fix/registry-teardown-before-slot-release onto devel and land it
   first. The bug is real and independently worth fixing, and it is the one
   finding here that names a race the design does not permit. Whether that alone
   turns the job green I can't claim: 18 reports survive the reader suppression, and
   a05ba3f names only the write_slot_payload/teardown_slot pairing of the two
   seen locally — the rest of that count has not been triaged.
2. Merge this now and accept a red sanitize (thread) on devel until the fix
   lands — honest, but a red default branch trains people to ignore it.
3. Put continue-on-error: true on the TSan job with a TODO referencing the
   registry fix. Gets the ASan/UBSan value immediately without a red branch, at
   the cost of a check nobody has to respect.

I would not recommend 3 as a permanent state: a non-blocking sanitizer job is a
sanitizer job that stops being read.

One correction this owes to the EventsExecutor PRs. What I reported there was
not a clean TSan run: #67 and #68 both say the suite is clean under
-fsanitize=thread except that "the only TSan reports in the suite remain the
pre-existing registry.cpp seqlock ones, which this stack does not touch". That
race is indeed pre-existing in devel and unrelated to those changes — but this
PR is what measures the thing I waved past. Once the reader side is suppressed,
"the pre-existing registry ones" is 18 reports from a single test binary, only one
pairing of which is attributed to a known fix. Discounting a whole class of report
by hand, on the strength of one run, is weaker evidence than it reads as.