Investigate lost transactions on mempool state resync

[goshawk-3]

Describe the bug
In test-harness, on sending 40 valid transactions in a row, mempool manages to process/accept around 70% of them. As an experiment, changing mempool processing from concurrent to sequential execution did improve the acceptance rate to 100%.

To Reproduce

1. Build up 40 transactions in all network mempool instances.
2. rm -f mempool.db of node_1
3. Restart node_1
4. As a result node_1 will request mempool updates from the network but only 29 transactions are accepted.

Expected behaviour
Mempool should always queue and process any sent transaction.

[goshawk-3]

The culprit of the observed issue is UDP messages getting dropped. The number chunks lost exceed the recovery rate that RaptorQ algorithm is adjusted for.

Test_1

1. Set up and bootstrap a network where mempool stores 391 transactions
2. A empty node joins the network
3. The newly joined node manages to download up to 80 transactions only
4. UDP drops reported locally

2132 drops at location 0xffffffff999a1682 [software]

Test_2 Output

2048 drops at location 0xffffffff999a1682 [software]
1 drops at location 0xffffffff998db415 [software]
343 drops at location 0xffffffff999a1682 [software]

Additionally, introducing a rate limiter (20 send requests per second) allowed the newly joined node to download all 391 transactions. The culprit should be addressed with another issue.