Add new ConfirmationTarget variant for min mempool feerates

Now that we support channels with anchor outputs, we add a new
ConfirmationTarget variant that, for now, will only apply to such
channels. This new variant should target estimating the minimum feerate
required to be accepted into most node mempools across the network.

Author: wpaulino

fuzz/src/chanmon_consistency.rs

@@ -78,7 +78,7 @@ impl FeeEstimator for FuzzEstimator {
 		// Background feerate which is <= the minimum Normal feerate.
 		match conf_target {
 			ConfirmationTarget::HighPriority => MAX_FEE,
-			ConfirmationTarget::Background => 253,
+			ConfirmationTarget::Background|ConfirmationTarget::MempoolMinimum => 253,
 			ConfirmationTarget::Normal => cmp::min(self.ret_val.load(atomic::Ordering::Acquire), MAX_FEE),
 		}
 	}

lightning/src/chain/chaininterface.rs

@@ -35,15 +35,24 @@ pub trait BroadcasterInterface {
 	fn broadcast_transactions(&self, txs: &[&Transaction]);
 }
 
-/// An enum that represents the speed at which we want a transaction to confirm used for feerate
+/// An enum that represents the priority at which we want a transaction to confirm used for feerate
 /// estimation.
 #[derive(Clone, Copy, Debug, Hash, PartialEq, Eq)]
 pub enum ConfirmationTarget {
-	/// We are happy with this transaction confirming slowly when feerate drops some.
+	/// We'd like a transaction to confirm in the future, but don't want to commit most of the fees
+	/// required to do so yet. The remaining fees will come via a Child-Pays-For-Parent (CPFP) fee
+	/// bump of the transaction.
+	///
+	/// The feerate returned should be the absolute minimum feerate required to enter most node
+	/// mempools across the network. Note that if you are not able to obtain this feerate estimate,
+	/// you should likely use the furthest-out estimate allowed by your fee estimator.
+	MempoolMinimum,
+	/// We are happy with a transaction confirming slowly, at least within a day or so worth of
+	/// blocks.
 	Background,
-	/// We'd like this transaction to confirm without major delay, but 12-18 blocks is fine.
+	/// We'd like a transaction to confirm without major delayed, i.e., within the next 12-24 blocks.
 	Normal,
-	/// We'd like this transaction to confirm in the next few blocks.
+	/// We'd like a transaction to confirm in the next few blocks.
 	HighPriority,
 }