Merge bitcoin/bitcoin#25215: [kernel 2d/n] Reduce CTxMemPool constructor call sites

d273e53b6e2cabd91a83f0ff0f9b6cfe1815b637 bench/rpc_mempool: Create ChainTestingSetup, use its CTxMemPool (Carl Dong)
020caba3df727ae8ede50eace86ae76971c0fea1 bench: Use existing CTxMemPool in TestingSetup (Carl Dong)
86e732def3983f99ec84b59375615bedcdc0e664 scripted-diff: test: Use CTxMemPool in TestingSetup (Carl Dong)
213457e170ce41a0b26c644aa010111df36414a6 test/policyestimator: Use ChainTestingSetup's CTxMemPool (Carl Dong)
319f0ceeeb25f28e027fc41be2755092dc5365b4 rest/getutxos: Don't construct empty mempool (Carl Dong)
03574b956a274207ba90591781e0914609225136 tree-wide: clang-format CTxMemPool references (Carl Dong)

Pull request description:

  This is part of the `libbitcoinkernel` project: #24303, https://github.com/bitcoin/bitcoin/projects/18

  This PR reduces the number of call sites where we explicitly construct CTxMemPool. This is done in preparation for later PRs which decouple the mempool module from `ArgsManager`, eventually all of libbitcoinkernel will be decoupled from `ArgsManager`.

  The changes in this PR:

  - Allows us to have less code churn as we modify `CTxMemPool`'s constructor in later PRs
  - In many cases, we can make use of existing `CTxMemPool` instances, getting rid of extraneous constructions
  - In other cases, we construct a `ChainTestingSetup` and use the `CTxMemPool` there, so that we can rely on the logic in `setup_common` to set things up correctly

  ## Notes for Reviewers

  ### A note on using existing mempools

  When evaluating whether or not it's appropriate to use an existing mempool in a `*TestingSetup` struct, the key is to make sure that the mempool has the same lifetime as the `*TestingSetup` struct.

  Example 1: In [`src/fuzz/tx_pool.cpp`](https://github.com/bitcoin/bitcoin/blob/b4f686952a60bbadc7ed2250651d0d6af0959f4d/src/test/fuzz/tx_pool.cpp), the `TestingSetup` is initialized in `initialize_tx_pool` and lives as a static global, while the `CTxMemPool` is in the `tx_pool_standard` fuzz target, meaning that each time the `tx_pool_standard` fuzz target gets run, a new `CTxMemPool` is created. If we were to use the static global `TestingSetup`'s CTxMemPool we might run into problems since its `CTxMemPool` will carry state between subsequent runs. This is why we don't modify `src/fuzz/tx_pool.cpp` in this PR.

  Example 2: In [`src/bench/mempool_eviction.cpp`](https://github.com/bitcoin/bitcoin/blob/b4f686952a60bbadc7ed2250651d0d6af0959f4d/src/bench/mempool_eviction.cpp), we see that the `TestingSetup` is in the same scope as the constructed `CTxMemPool`, so it is safe to use its `CTxMemPool`.

  ### A note on checking `CTxMemPool` ctor call sites

  After the "tree-wide: clang-format CTxMemPool references" commit, you can find all `CTxMemPool` ctor call sites with the following command:

  ```sh
  git grep -E -e 'make_unique<CTxMemPool>' \
              -e '\bCTxMemPool\s+[^({;]+[({]' \
              -e '\bCTxMemPool\s+[^;]+;' \
              -e '\bnew\s+CTxMemPool\b'
  ```

  At the end of the PR, you will find that there are still quite a few call sites that we can seemingly get rid of:

  ```sh
  $ git grep -E -e 'make_unique<CTxMemPool>' -e '\bCTxMemPool\s+[^({;]+[({]' -e '\bCTxMemPool\s+[^;]+;' -e '\bnew\s+CTxMemPool\b'
  # rearranged for easier explication
  src/init.cpp:        node.mempool = std::make_unique<CTxMemPool>(node.fee_estimator.get(), mempool_check_ratio);
  src/test/util/setup_common.cpp:    m_node.mempool = std::make_unique<CTxMemPool>(m_node.fee_estimator.get(), 1);
  src/rpc/mining.cpp:        CTxMemPool empty_mempool;
  src/test/util/setup_common.cpp:    CTxMemPool empty_pool;
  src/bench/mempool_stress.cpp:    CTxMemPool pool;
  src/bench/mempool_stress.cpp:    CTxMemPool pool;
  src/test/fuzz/rbf.cpp:    CTxMemPool pool;
  src/test/fuzz/tx_pool.cpp:    CTxMemPool tx_pool_{/*estimator=*/nullptr, /*check_ratio=*/1};
  src/test/fuzz/tx_pool.cpp:    CTxMemPool tx_pool_{/*estimator=*/nullptr, /*check_ratio=*/1};
  src/test/fuzz/validation_load_mempool.cpp:    CTxMemPool pool{};
  src/txmempool.h:    /** Create a new CTxMemPool.
  ```
  Let's break them down one by one:

  ```
  src/init.cpp:        node.mempool = std::make_unique<CTxMemPool>(node.fee_estimator.get(), mempool_check_ratio);
  src/test/util/setup_common.cpp:    m_node.mempool = std::make_unique<CTxMemPool>(m_node.fee_estimator.get(), 1);
  ```

  Necessary

  -----

  ```
  src/rpc/mining.cpp:        CTxMemPool empty_mempool;
  src/test/util/setup_common.cpp:    CTxMemPool empty_pool;
  ```

  These are fixed in #25223 where we stop requiring the `BlockAssembler` to have a `CTxMemPool` if it's not going to consult it anyway (as is the case in these two call sites)

  -----

  ```
  src/bench/mempool_stress.cpp:    CTxMemPool pool;
  src/bench/mempool_stress.cpp:    CTxMemPool pool;
  ```

  Fixed in #24927.

  -----

  ```
  src/test/fuzz/rbf.cpp:    CTxMemPool pool;
  src/test/fuzz/tx_pool.cpp:    CTxMemPool tx_pool_{/*estimator=*/nullptr, /*check_ratio=*/1};
  src/test/fuzz/tx_pool.cpp:    CTxMemPool tx_pool_{/*estimator=*/nullptr, /*check_ratio=*/1};
  src/test/fuzz/validation_load_mempool.cpp:    CTxMemPool pool{};
  ```

  These are all cases where we don't want the `CTxMemPool` state to persist between runs, see the previous section "A note on using existing mempools"

  -----

  ```
  src/txmempool.h:    /** Create a new CTxMemPool.
  ```

  It's a comment (someone link me to a grep that understands syntax plz thx)

ACKs for top commit:
  laanwj:
    Code review ACK d273e53b6e2cabd91a83f0ff0f9b6cfe1815b637

Tree-SHA512: c4ff3d23217a7cc4a7145defc7b901725073ef73bcac3a252ed75f672c87e98ca0368d1d8c3f606b5b49f641e7d8387d26ef802141b650b215876f191fb6d5f9

0 files changed, 0 insertions, 0 deletions