Follow up from #34329.
Private broadcast transaction data is removed from memory when either 1) the tx is received back from another peer and inserted into our mempool or 2) the tx is no longer acceptable to our mempool.
We want to persist this data for a number of reasons. See #30471.
This PR changes the behavior of the private broadcast queue to keep received and mempool-rejected txs in memory. The peer’s address we received the tx from and the time, or the mempool rejection reason is now also returned via getprivatebroadcastinfo RPC.
Any tx that has been received back or is not acceptable to our mempool will not be picked by a private broadcast connection and will not be counted as pending. This maintains the current behavior of stopping broadcasting when these conditions are met.
When reattempting to broadcast stale private broadcast txs, every tx whether pending or not is checked for mempool acceptance. This has the added benefit of rebroadcasting previously received txs that have since been evicted from the mempool.
This is designed to facilitate follow up work including:
- rebroadcasting txs that are in our mempool but have not been confirmed after a while. This can obviate rebroadcasting wallet txs if private broadcast is enabled (see #34533 (comment)).
- adding a delay when submitting private broadcast txs so they will be broadcast at a later time (see #34118).
- persisting private broadcast state to disk for resuming after restart or crash (see #34322).
- expiring txs after a while so they are removed from the queue without having to manually abort.