refactor(p2p): merge FastTxCollection into TxCollection with sequential pipeline

[fcarreiro]

Summary

• Removes FastTxCollection as a separate class and absorbs all its logic directly into TxCollection
• Replaces the old parallel file-store delay with a single sequential pipeline: node RPC → reqresp → file store, where each phase blocks on the previous (cancellation-aware)
• File store collection is now driven by IRequestTracker — the same synchronization primitive used by node and reqresp paths. The tracker is the single source of truth for "is this tx still missing?" and "is this request still alive?"
• FileStoreTxCollection simplified: dropped start()/stop()/persistent worker pool/wakeSignal. startCollecting(requestTracker, context) returns Promise<void>, spins up its own per-call worker pool, and workers self-terminate when the tracker is cancelled (all-fetched / deadline / external)

Collection flow inside collectFast

1. Start node RPC collection in the background
2. Wait txCollectionFastNodesTimeoutBeforeReqRespMs — interruptible by cancellation or by node exhaustion (so when no nodes are configured, reqresp starts immediately)
3. Start reqresp in the background (parallel with nodes)
4. Wait txCollectionFileStoreFastDelayMs — interruptible by cancellation or reqresp completion
5. Start file store collection in the background (its workers self-terminate)
6. Promise.allSettled on node + reqresp + file store

txCollectionFileStoreFastDelayMs description updated to reflect it is now anchored to reqresp start, not collection start.

File store / tracker integration

• FileStoreTxCollection.startCollecting no longer takes (txHashes, context, deadline); it takes (requestTracker, context) and reads the missing txs + deadline from the tracker
• Workers check requestTracker.isMissing(hash) each scan — if the tx was found via another path (node/reqresp/gossipsub), the entry is dropped without an extra fetch
• Workers race their backoff sleeps against requestTracker.cancellationToken — cancelling a request (deadline, stopCollectingForBlocksUpTo/After, or stop()) propagates to file store workers immediately
• Removed foundTxs/clearPending plumbing on FileStoreTxCollection — the tracker handles both implicitly
• startCollecting yields once after building its entry set, so a synchronous follow-up call (e.g. markFetched in tests, or the gossipsub-found path in production) lands before workers begin scanning

Tests

• tx_collection.test.ts: collapsed the TestFastTxCollection subclass; all accesses go directly through TxCollection. Added "starts reqresp immediately when no nodes are configured" covering the node-exhaustion shortcut
• file_store_tx_collection.test.ts: rewritten for the new shape — no start()/stop(), lifecycle driven by the tracker (cancel to terminate workers). New "workers exit when tracker is cancelled" covers the per-call worker-pool teardown

Closes https://linear.app/aztec-labs/issue/A-933/tx-collection-dont-retrieve-transactions-that-have-already-been via new synchronization with the request tracker.

[fcarreiro]

• refactor(p2p): merge FastTxCollection into TxCollection with sequential pipeline #23245 👈 (View in Graphite)
• merge-train/spartan

This stack of pull requests is managed by Graphite. Learn more about stacking.

[AztecBot]

Flakey Tests

🤖 says: This CI run detected 1 tests that failed, but were tolerated due to a .test_patterns.yml entry.

\033FLAKED\033 (8;;http://ci.aztec-labs.com/b22d1e1ac820ccc7�b22d1e1ac820ccc78;;�): yarn-project/scripts/run_test.sh ethereum/src/test/tx_delayer.test.ts (110s) (code: 0)

[spalladino]

Heads up this changes the semantics of workerCount. If I understood correctly, now we have workerCount per request, not global. I think this is fine though, since worker count is not too high (defaults to 5).