policy: Allow any transaction version with < minrelay

Prior to cluster mempool, a policy was in place that
disallowed non-TRUC transactions from being
TX_RECONSIDERABLE in a package setting if it was below
minrelay. This was meant to simplify reasoning about mempool
trimming requirements with non-trivial transaction
topologies in the mempool. This is no longer a concern
post-cluster mempool, so this is relaxed.

In effect, this makes 0-value parent transactions relayable
through the network without the TRUC restrictions and
thus the anti-pinning protections.

doc/policy/packages.md

@@ -99,14 +99,6 @@ submitted as a package.
 transaction (i.e. in which a replacement transaction with a higher fee cannot be signed) being
 rejected from the mempool when transaction volume is high and the mempool minimum feerate rises.
 
-Note: Package feerate cannot be used to meet the minimum relay feerate (`-minrelaytxfee`)
-requirement. For example, if the mempool minimum feerate is 5sat/vB and the minimum relay feerate is
-set to 5sat/vB, a 1sat/vB parent transaction with a high-feerate child will not be accepted, even if
-submitted as a package. Note that this rule does not apply to
-[TRUC transactions](https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki) as an individual
-TRUC transaction is permitted to be below the mempool min relay feerate, assuming it is considered within
-a package that meets the mempool's feerate requirements.
-
 *Rationale*: Avoid situations in which the mempool contains non-bumped transactions below min relay
 feerate (which we consider to have pay 0 fees and thus receiving free relay). While package
 submission would ensure these transactions are bumped at the time of entry, it is not guaranteed