4999781 test: check custom ancestor limit in mempool_packages.py (Sebastian Falbesoner)

Pull request description:

  The functional test `mempool_packages.py` starts one node with default ancestor/descendant limit settings and one with a custom, reduced ancestor limit (currently `-limitancestorcount=5`). The effect of the latter had not been tested yet though. This is approached in this PR by checking on the expected mempool contents of node1 after the node0 ancestor tests are done, via the following three conditions:
  - the # of txs in the node1 mempool is equal to the the limit
  - all txs in node1 mempool are a subset of txs in node0 mempool
  - the node1 mempool txs match the start of the constructed tx-chain

  Note that this still doesn't *fully* check the expected mempool of node1 (e.g. that it isn't influenced by `prioritisetransaction` RPC on node0), hence I add another TODO. In the future it would make sense to also set a custom descendant limit when the second TODO about checking node1's mempool is approached: https://github.com/bitcoin/bitcoin/blob/89e93135aedf984f7a98771f047e2beb6cdbdb8e/test/functional/mempool_packages.py#L228

ACKs for top commit:
  MarcoFalke:
    ACK 4999781 👲

Tree-SHA512: d3a1d19fb49731238ad08ee7c02e2fa81a227e3b4ef3340d68598de42ddb62be9161134f6b8e08fa76b8c9faa02fecfa01111159642e20e9f358292a757b7608

b902bd6 test: check custom descendant limit in mempool_packages.py (Sebastian Falbesoner)

Pull request description:

  This is a follow-up PR to #17435, testing the custom descendant limit, passed by the argument `-limitdescendantcount`. ~~It was more tricky than expected, mainly because we don't know for sure at which point node1 has got all the transactions broadcasted from node0 (for the ancestor test this wasn't a problem since the txs were immediately available through `invalidateblock`) -- a simple `sync_mempools()` doesn't work here since the mempool contents are not equal due to different ancestor/descendant limits. Hence I came up with a "hacky manual sync":~~
  1. ~~wait until the mempool has the _expected_ tx count (see conditions below)~~
  2. ~~after that, wait some time and get sure that the mempool contents haven't changed in-between~~

  ~~Like for~~ Similar to the ancestor test, we overall check for ~~three~~ four conditions:
  - the # of txs in the node1 mempool is equal to the descendant limit (plus 1 for the parent tx, plus the # txs from the previous ancestor test which are still in) ~~(done by the hacky sync above)~~
  - all txs in node1 mempool are a subset of txs in node0 mempool
  - part of the constructed descendant-chain (the first ones up to the limit) are contained in node1 mempool
  - the remaining part of the constructed descendant-chain (all after the first ones up to the limit) is *not* contained in node1 mempool

ACKs for top commit:
  JeremyRubin:
    Excellent. utACK b902bd6

Tree-SHA512: 7de96dd248f16ab740e178ac5b64b57ead18cdcf74adfe989709d215e4a67b6b6d20de22c48e885d5f2edc55caaddd44a4261e996c5c87687ceb6a47f1d1fdaf

…ackages.py

b902bd6 test: check custom descendant limit in mempool_packages.py (Sebastian Falbesoner)

Pull request description:

  This is a follow-up PR to bitcoin#17435, testing the custom descendant limit, passed by the argument `-limitdescendantcount`. ~~It was more tricky than expected, mainly because we don't know for sure at which point node1 has got all the transactions broadcasted from node0 (for the ancestor test this wasn't a problem since the txs were immediately available through `invalidateblock`) -- a simple `sync_mempools()` doesn't work here since the mempool contents are not equal due to different ancestor/descendant limits. Hence I came up with a "hacky manual sync":~~
  1. ~~wait until the mempool has the _expected_ tx count (see conditions below)~~
  2. ~~after that, wait some time and get sure that the mempool contents haven't changed in-between~~

  ~~Like for~~ Similar to the ancestor test, we overall check for ~~three~~ four conditions:
  - the # of txs in the node1 mempool is equal to the descendant limit (plus 1 for the parent tx, plus the # txs from the previous ancestor test which are still in) ~~(done by the hacky sync above)~~
  - all txs in node1 mempool are a subset of txs in node0 mempool
  - part of the constructed descendant-chain (the first ones up to the limit) are contained in node1 mempool
  - the remaining part of the constructed descendant-chain (all after the first ones up to the limit) is *not* contained in node1 mempool

ACKs for top commit:
  JeremyRubin:
    Excellent. utACK b902bd6

Tree-SHA512: 7de96dd248f16ab740e178ac5b64b57ead18cdcf74adfe989709d215e4a67b6b6d20de22c48e885d5f2edc55caaddd44a4261e996c5c87687ceb6a47f1d1fdaf

…ackages.py

b902bd6 test: check custom descendant limit in mempool_packages.py (Sebastian Falbesoner)

Pull request description:

  This is a follow-up PR to bitcoin#17435, testing the custom descendant limit, passed by the argument `-limitdescendantcount`. ~~It was more tricky than expected, mainly because we don't know for sure at which point node1 has got all the transactions broadcasted from node0 (for the ancestor test this wasn't a problem since the txs were immediately available through `invalidateblock`) -- a simple `sync_mempools()` doesn't work here since the mempool contents are not equal due to different ancestor/descendant limits. Hence I came up with a "hacky manual sync":~~
  1. ~~wait until the mempool has the _expected_ tx count (see conditions below)~~
  2. ~~after that, wait some time and get sure that the mempool contents haven't changed in-between~~

  ~~Like for~~ Similar to the ancestor test, we overall check for ~~three~~ four conditions:
  - the # of txs in the node1 mempool is equal to the descendant limit (plus 1 for the parent tx, plus the # txs from the previous ancestor test which are still in) ~~(done by the hacky sync above)~~
  - all txs in node1 mempool are a subset of txs in node0 mempool
  - part of the constructed descendant-chain (the first ones up to the limit) are contained in node1 mempool
  - the remaining part of the constructed descendant-chain (all after the first ones up to the limit) is *not* contained in node1 mempool

ACKs for top commit:
  JeremyRubin:
    Excellent. utACK b902bd6

Tree-SHA512: 7de96dd248f16ab740e178ac5b64b57ead18cdcf74adfe989709d215e4a67b6b6d20de22c48e885d5f2edc55caaddd44a4261e996c5c87687ceb6a47f1d1fdaf