TSAN reports a data race on g.checkpoint_quit:

ThreadSanitizer reports a data race on the global g.checkpoint_quit flag:

• Write by T51 in disagg_async_stepdown (test/format/format_disagg.c:270)
• Read by T49 in checkpoint (test/format/checkpoint.c:88)
• Location is global g …

checkpoint_quit and timestamp_quit in format.h are declared volatile bool, but plain volatile reads/writes are not atomic. TSAN correctly flags unsynchronized concurrent accesses between:

• The stepdown thread (disagg_async_stepdown) writing the flags, and
• The checkpoint/timestamp threads reading them in their loop conditions.

To fix this, switch all reads and writes of these two flags to the existing atomic helpers from tsan_suppress.h:

• __wt_atomic_load_bool_v_relaxed()
• __wt_atomic_store_bool_v_relaxed()

These operate on volatile bool * and use compiler atomic builtins that TSAN recognizes as synchronized. Relaxed ordering is sufficient because these are simple stop-signal flags and do not guard any other shared state.

Changes:

• test/format/checkpoint.c: read checkpoint_quit via atomic load in the checkpoint loop condition.
• test/format/format_timestamp.c: read timestamp_quit via atomic load in the timestamp loop condition.
• test/format/format_disagg.c: write checkpoint_quit / timestamp_quit via atomic store at all four call sites in disagg_async_stepdown.

No functional or behavioral change; this only fixes the TSAN-reported data race on unsynchronized flag access.

Evergreen failure link - https://parsley.corp.mongodb.com/evergreen/wiredtiger_amazon2023_arm64_tsan_format_stress_test_disagg_switch_tsan_patch_4369745f31437c73ec4c54f7beb26d114c3390b1_6a59c76c142f4d00075b4049_26_07_17_06_11_06/0/task?bookmarks=0,1489