* Fix ASAN shutdown leaks in C API tests
The test framework destroys databases/transactions via shared_ptr drop which
queues cleanup via onMainThreadVoid. Without flushing, fdb_stop_network() is
called before the network thread processes these callbacks, leaving
allocations unreachable and triggering LSAN reports.
For test binaries (fdb_c_api_tester, shim_lib_tester): flush the network
thread's onMainThread queue deterministically by round-tripping through it —
create a temporary database and call getServerProtocol (which dispatches
through onMainThread). When it returns, all prior queued callbacks have
executed.
For external client threads (MultiVersionApi::stopNetwork()): use
threadSleep(3) because no deterministic flush is available. External clients
run their own Net2 instances in separate threads, and the DL API does not
expose any call that dispatches to the external client's onMainThread queue
and blocks until completion.
All guarded by #ifdef ADDRESS_SANITIZER — zero impact on non-ASAN builds.
Related: #13188, #13242, #13255, #13278, #13288, #13296
* Exclude multi_process fdbcli tests from ASAN builds
These tests take >40 minutes under ASAN instrumentation, exceeding any
reasonable CI timeout. The single_process variants are already excluded
with the same pattern.
* Add runNetworkThread LSAN suppression for external client shutdown leaks
External client .so copies have the same Peer/connection shutdown leaks
already suppressed for the main client (Peer::Peer, connectionKeeper, etc.),
but LSAN cannot symbolize their stacks — frames show only offsets, not
function names. runNetworkThread is the thread entry point for external
client network threads and does not affect main client leak detection.
Attempted alternatives that proved unreliable:
- threadSleep(1-3s) before stopping external clients: race condition
- Deterministic flush via createDatabase+getServerProtocol: only flushes
the local client, not external client network threads (external clients
run their own Net2 instances and the DL API does not expose a call that
dispatches to their onMainThread queue and blocks until completion)
Related: #13188, #13242, #13255, #13278, #13288, #13296
DeterministicRandom() can use a boost::random::mt19937_64
to take a 64-bit seed and return 64-bit random values,
and this simplifies things because fdb always wants 64 bits.
Performance should be slightly better because the 32-bit
mt19937 was always called twice to get 64 bits.
* fix: use thread-local mt19937_64 for automatic idempotency ID
* feat: add platform::getRandomBytes and use it for idempotency IDs
* fix: pr fixes + getentropy support
* fix: pr review changes
Trevor Clinkenbeard