Merge bitcoin/bitcoin#30111: locks: introduce mutex for tx download, flush rejection filters once per tip change

c85accecafc20f6a6ae94bdf6cdd3ba9747218fd [refactor] delete EraseTxNoLock, just use EraseTx (glozow)
6ff84069a5dd92303ed2ec28f0ec7c96bbda3938 remove obsoleted TxOrphanage::m_mutex (glozow)
61745c7451ec64b26c74f672c688e82efb3b96aa lock m_recent_confirmed_transactions using m_tx_download_mutex (glozow)
723ea0f9a5b5e3f3f58ea049a98299ff0ebde468 remove obsoleted hashRecentRejectsChainTip (glozow)
18a43552509603ddf83b752fd7b4b973ba1dcf82 update recent_rejects filters on ActiveTipChange (glozow)
36f170d87924e50d0ff9be2a1b0f2a8f13950a9b add ValidationInterface::ActiveTipChange (glozow)
3eb1307df0a38ac4ea52995fbb03ead37387b41e guard TxRequest and rejection caches with new mutex (glozow)

Pull request description:

  See #27463 for full project tracking.

  This contains the first few commits of #30110, which require some thinking about thread safety in review.
  - Introduce a new `m_tx_download_mutex` which guards the transaction download data structures including `m_txrequest`, the rolling bloom filters, and `m_orphanage`. Later this should become the mutex guarding `TxDownloadManager`.
    - `m_txrequest` doesn't need to be guarded using `cs_main` anymore
    - `m_recent_confirmed_transactions` doesn't need its own lock anymore
    - `m_orphanage` doesn't need its own lock anymore
  - Adds a new `ValidationInterface` event, `ActiveTipChanged`, which is a synchronous callback whenever the tip of the active chainstate changes.
  - Flush `m_recent_rejects` and `m_recent_rejects_reconsiderable` on `ActiveTipChanged` just once instead of checking the tip every time `AlreadyHaveTx` is called. This should speed up calls to that function (no longer comparing a block hash each time) and removes the need to lock `cs_main` every time it is called.

  Motivation:
  - These data structures need synchronization. While we are holding `m_tx_download_mutex`, these should hold:
    - a tx hash in `m_txrequest` is not also in `m_orphanage`
    - a tx hash in `m_txrequest` is not also in `m_recent_rejects` or `m_recent_confirmed_transactions`
    - In the future, orphan resolution tracking should also be synchronized. If a tx has an entry in the orphan resolution tracker, it is also in `m_orphanage`, and not in `m_txrequest`, etc.
  - Currently, `cs_main` is used to e.g. sync accesses to `m_txrequest`. We should not broaden the scope of things it locks.
  - Currently, we need to know the current chainstate every time we call `AlreadyHaveTx` so we can decide whether we should update it. Every call compares the current tip hash with `hashRecentRejectsChainTip`. It is more efficient to have a validation interface callback that updates the rejection filters whenever the chain tip changes.

ACKs for top commit:
  instagibbs:
    reACK c85accecafc20f6a6ae94bdf6cdd3ba9747218fd
  dergoegge:
    Code review ACK c85accecafc20f6a6ae94bdf6cdd3ba9747218fd
  theStack:
    Light code-review ACK c85accecafc20f6a6ae94bdf6cdd3ba9747218fd
  hebasto:
    ACK c85accecafc20f6a6ae94bdf6cdd3ba9747218fd, I have reviewed the code and it looks OK.

Tree-SHA512: c3bd524b5de1cafc9a10770dadb484cc479d6d4c687d80dd0f176d339fd95f73b85cb44cb3b6b464d38a52e20feda00aa2a1da5a73339e31831687e4bd0aa0c5

0 files changed, 0 insertions, 0 deletions