Avoid adding transactions below min relay feerate because, even if they
were bumped through CPFP when entering the mempool, we do not have a
DoS-resistant way of ensuring they always remain bumped.  In the future,
this rule can be relaxed (e.g. to allow packages to bump 0-fee
transactions) if we find a way to do so.

Avoid calling PackageMempoolChecks() when there is only 1 transaction.
Note to reviewers: there is a slight change in the error type returned,
as shown in the txpackage_tests change.  When a transaction is the last
one left in the package and its fee is too low, this returns a PCKG_TX
instead of PCKG_POLICY. This interface is clearer;
"package-fee-too-low" for 1 transaction would be a bit misleading.

At this point it's not expected that there are any such transactions,
except from reorgs.

The intention of the test is to set a high -minrelaytxfee
such that these transactions are rejected in LoadMempool() and
in CWallet::ResumbitWalletTransactions().

However, while the parent transactions are below minrelaytxfee, they
each have descendants high enough feerate to bump them past the
minrelaytxfee (observe that the `assert_greater_than` checks fail
if given the original amount of 0.0001). These transactions will be kept
after the mempool persists packages, which is an improvement, but will
cause the original test to fail.

Hold pool.cs the entire time otherwise wallet resubmissions may call
TrimtoSize() in between loading transactions from disk.

-BEGIN VERIFY SCRIPT-
sed -i 's/CheckPackage(/IsPackageWellFormed(/g' $(git grep -l CheckPackage)
-END VERIFY SCRIPT-

We cannot require that peers send topologically sorted lists, because we
cannot check for this property without ensuring we have the same chain
tip and ensuring we have the full ancestor set. Instead, add the ability
to handle arbitrarily ordered transaction lists.

Packageifier calculates the in-package ancestors. We already know
this tx will fail because it depends on something invalid (specifically
for a non-policy reason). We also know that it is missing at least one
input (the tx that did not and will not make it into our mempool). Just
return missing inputs directly.

Note to reviewers: slight behavior change. If this tx has multiple
errors, there may be a difference in which one is returned.  For
example, if the tx has a dust output in addition to relying on
the invalid tx, we will return TX_MISSING_INPUTS when we previously
would have returned TX_NOT_STANDARD. This is simply because dust is
checked earlier within PreChecks().

Add a test that we don't quit *too* early and reject transactions we
should keep.

…ackages

This results in the incentive-compatible transactions ending up in our
mempool. Prior to this commit, if parents within the package relied on
each other, we could end up (1) accepting a low-feerate child or (2)
rejecting high-feerate parents. Instead of validating each transaction
*individually* in turn, validate each one with their in-package ancestor
set. This means parents with inter-dependencies are validated correctly,
while we continue using aggregate totals for package feerate.

…parents

We can safely allow any ancestor package since Packageifier can handle
things that are out of order. Remove the check that "all unconfirmed
parents are present" because, even if a tx is missing inputs, the other
transactions may be worth validating.

Create TxPackageTracker module, responsible for handling orphan
resolution. Enable node to retry orphan parent downloading from multiple
peers who announced the tx. Use preferred peers and avoid overloading
peers with too many requests.

Making the orphanage more reliable is also necessary because it becomes
part of the "critical path" for some transactions.  A 0-fee parent
bumped by a child *must* be relayed via package relay; if the orphanage
overflows or is churned by a malicious peer, the package would be
censored from the network.

No effect for now.
TODO: add per-peer limits on orphan memory usage

…tion

No behavior change in this commit.

Adding/deleting is now strictly handled by TxPackageTracker, and should
not be exposed to the public.

Makes orphan handling more robust. We will also use the orphan
resolution tracker for requesting ancpkginfo. The timeout in
p2p_segwit.py has been increased to account for the fact that parents
are no longer immediately requested.

…ow fees

We wouldn't want to add a low-feerate transaction to m_recent_rejects
because usually that means we won't give the child a chance
(`fRejectedParents`); we instead want to fetch this orphan's low-feerate
parents and potentially accept them.  However, we also shouldn't
revalidate transactions/packages that have already been rejected.
Continue to cache low-fee rejections, but separately.

Note: when ephemeral anchor transaction fails due to a missing spender,
we should similarly put it in the reconsiderable filter.

Conditions for responding to an ancpkginfo request are identical to
responding to a tx. That is, we only provide ancpkginfo if we would have
provided tx data as well.
(HACKY AND UNSAFE)

… tracker

For now, each tx in ancpkginfo is treated like an individual tx
announcement. When the tx arrives, it is validated individually as well.

FIXME: packagehash for python tests

These transactions can be more common with package relay, but
non-package-relay peers will only waste bandwidth and orphanage space,
then end up not accepting them. Save their bandwidth by dropping
announcements of transactions that have below-fee-filter parents.