test: p2p_blocksonly.py relay-permission tx relay timeout under TSAN

[thepastaclaw]

Failure

linux64_tsan-test / Test source intermittently failed in p2p_blocksonly.py on PR #7397 at head 2dd61907eab50330f8478cc03c28962f2d596be7.

CI job: https://github.com/dashpay/dash/actions/runs/28535534402/job/84600570160
Artifact: test_logs-linux64_tsan-2dd61907

Observed mode

The test timed out in the relay-permission section:

p2p_blocksonly.py:77 second_peer.wait_for_tx(txid)
AssertionError: predicate not true after 240.0 seconds

The node accepted the transaction and queued an inventory announcement for the second peer, but the peer never received the tx before the functional-test timeout:

AcceptToMemoryPool: peer=0: accepted 1a379b51934c0da5408fd43b1ed408f99dd2ae29be34c8963d54c88f16da8b85
PushInv -- adding new inv: tx 1a379b51934c0da5408fd43b1ed408f99dd2ae29be34c8963d54c88f16da8b85 peer=1

No SendMessages -- queued inv entry for peer 1 appeared before shutdown, so this looks like timing/scheduling flakiness in the test's relay wait under TSAN rather than a validation or mempool rejection.

Scope notes

PR #7397 is a master into develop merge-back plus a one-line header self-containment fix. It does not touch test/functional/p2p_blocksonly.py. Earlier in the same failing run, the RPC transaction relay path in p2p_blocksonly.py passed for the same txid, and the failure happened only in the later relay-permission wait.

Reproduction

The observed environment was the GitHub Actions linux64_tsan job. A focused reproduction would be repeated runs of:

test/functional/p2p_blocksonly.py --timeout-factor=<CI/TSAN factor>

with TSAN build binaries, watching for the relay-permission second_peer.wait_for_tx(txid) timeout after the node logs PushInv -- adding new inv ... peer=1.