Merge bitcoin/bitcoin#31385: package validation: relax the package-not-child-with-unconfirmed-parents rule

ea17a9423f [doc] release note for relaxing requirement of all unconfirmed parents present (glozow)
12f48d5ed3 test: add chained 1p1c propagation test (Greg Sanders)
525be56741 [unit test] package submission 2p1c with 1 parent missing (glozow)
f24771af05 relax child-with-unconfirmed-parents rule (glozow)

Pull request description:

  Broadens the package validation interface, see #27463 for wider context.

  On master, package rules include that (1) the package topology must be child-wth-parents (2) all of the child's unconfirmed parents must be present. This PR relaxes the second rule, leaving the first rule untouched (there are plans to change that as well, but not here).

  Original motivation for this rule was based on the idea that we would have a child-with-unconfirmed-parents package relay protocol, and this would verify that the peer provided the "correct" package. For various reasons, we're not planning on doing this. We could potentially do this for ancestor packages (with a similar definition that all UTXOs to make the tx valid are available in this package), but it's also questionable whether it's useful to enforce this.

  This rule gets in the way of certain usage of 1p1c package relay currently. If a transaction has multiple parents, of which only 1 requires a package CPFP, this rule blocks the package from relaying. Even if all the non-low-feerate parents are already in mempool, when the p2p logic submits the 1p1c package, it gets rejected for not meeting this rule.

ACKs for top commit:
  ishaanam:
    re-utACK ea17a9423f
  instagibbs:
    ACK ea17a9423f

Tree-SHA512: c2231761ae7b2acea10a96735e7a36c646f517964d0acb59bacbae1c5a1950e0223458b84c6d5ce008f0c1d53c1605df0fb3cd0064ee535ead006eb7c0fa625b

doc/policy/packages.md

@@ -8,11 +8,9 @@ Graph (a directed edge exists between a transaction that spends the output of an
 For every transaction `t` in a **topologically sorted** package, if any of its parents are present
 in the package, they appear somewhere in the list before `t`.
 
-A **child-with-unconfirmed-parents** package is a topologically sorted package that consists of
-exactly one child and all of its unconfirmed parents (no other transactions may be present).
-The last transaction in the package is the child, and its package can be canonically defined based
-on the current state: each of its inputs must be available in the UTXO set as of the current chain
-tip or some preceding transaction in the package.
+A **child-with-parents** package is a topologically sorted package that consists of exactly one child and at least one
+of its unconfirmed parents.  Not all unconfirmed parents need to be present but no other transactions may be present; the
+parent of a parent should not be in this package (unless this "grandparent" is also a direct parent of the child).
 
 ## Package Mempool Acceptance Rules
 
@@ -73,7 +71,7 @@ The following rules are enforced for all packages:
 The following rules are only enforced for packages to be submitted to the mempool (not
 enforced for test accepts):
 
-* Packages must be child-with-unconfirmed-parents packages. This also means packages must contain at
+* Packages must be child-with-parents packages. This also means packages must contain at
   least 1 transaction. (#31096)
 
    - *Rationale*: This allows for fee-bumping by CPFP. Allowing multiple parents makes it possible

doc/release-notes-31385.md

@@ -0,0 +1,14 @@
+RPC
+
+The `submitpackage` RPC, which allows submissions of child-with-parents
+packages, no longer requires that all unconfirmed parents be present. The
+package may contain other in-mempool ancestors as well. (#31385)
+
+P2P
+
+Opportunistic 1-parent-1-child package relay has been improved to handle
+situations when the child already has unconfirmed parent(s) in the mempool.
+This means that 1p1c packages can be accepted and propagate, even if they are
+connected to broader topologies: multi-parent-1-child (where only 1 parent
+requires fee-bumping), grandparent-parent-child (where only parent requires
+fee-bumping) etc. (#31385)