fix p2p_compactblocks flakiness

Summary:
p2p_compactblocks has been failing lately, example:
https://build.bitcoinabc.org/viewLog.html?buildId=28193

The reason is a bit subtle, and involves both CTOR and an
apparent (mild) bug in the handling of orphan transactions.

• When it fails, it is expecting a getdata-block with a single hash. It receives the getdata-block BUT also a getdata-tx with five txids. Hence the error message 5 != 1.
• It doesn't make sense that any getdata-tx is sent at this time. This test case is test_incorrect_blocktxn_response and the reason for the getdata-tx is THREE TEST CASES EARLIER in test_getblocktxn_requests.
• test_getblocktxn_requests is sending 10 transactions out of order. Many of them get put in orphan pool, but eventually they are de-orphaned (accepted) and they are all mined.
• For some reason, bitcoind is re-requesting txes that had been de-orphaned a long time ago. (see stuff about tx_process_time in net_processing.cpp) This is probably a bug.

This fix doesn't address the root cause bug but does make this test
not induce orphan transactions, which probably it shouldn't be
relying on in the first place. I will be looking into the origin
of the incorrect orphan tx handling as well.

Test Plan:

ninja all
./test/functional/test_runner.py --nocleanup p2p_compactblocks

Examine node debug.logs to ensure the absence of "orphan tx" logs
and spurious "Requesting tx" logs (they may occur when node0 and
node1 talk to each other, in which case they will happen
immediately after receiving a tx INV from the partner node.)

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D5176