Allow configuring different max fee rate from peer

We've run into issues a few times where channels will get force closed because CLN's fee estimator isn't as good as ours so the fee rate will be too high, resulting in a force close. It'd be nice if we'd have the ability to be able to increase this limit because generally this isn't malicious, just different views of the mempool.

This also allows you to decrease the max fee if you think it is too
high.

Author: benthecarman

lightning/src/chain/chaininterface.rs

@@ -85,6 +85,13 @@ pub trait FeeEstimator {
 	///  * satoshis-per-byte * 250
 	///  * satoshis-per-kbyte / 4
 	fn get_est_sat_per_1000_weight(&self, confirmation_target: ConfirmationTarget) -> u32;
+
+	/// Gets the maximum fee rate we'd accept from a channel counterparty.
+	/// By default we'll accept up to 25 sat/vByte or 10x our fee estimator's "High Priority" fee.
+	/// This can be used to increase or decrease that limit.
+	fn max_counterparty_selected_feerate(&self) -> u64 {
+		cmp::max(250 * 25, self.get_est_sat_per_1000_weight(ConfirmationTarget::HighPriority) as u64 * 10)
+	}
 }
 
 /// Minimum relay fee as required by bitcoin network mempool policy.
@@ -113,6 +120,12 @@ impl<F: Deref> LowerBoundedFeeEstimator<F> where F::Target: FeeEstimator {
 			FEERATE_FLOOR_SATS_PER_KW,
 		)
 	}
+
+	pub fn bounded_max_counterparty_selected_feerate(&self) -> u64 {
+		cmp::max(
+			self.0.max_counterparty_selected_feerate(),
+			FEERATE_FLOOR_SATS_PER_KW as u64)
+	}
 }
 
 #[cfg(test)]

lightning/src/ln/channel.rs

@@ -2149,14 +2149,13 @@ impl<SP: Deref> Channel<SP> where
 	) -> Result<(), ChannelError> where F::Target: FeeEstimator, L::Target: Logger,
 	{
 		// We only bound the fee updates on the upper side to prevent completely absurd feerates,
-		// always accepting up to 25 sat/vByte or 10x our fee estimator's "High Priority" fee.
+		// by default accepting up to 25 sat/vByte or 10x our fee estimator's "High Priority" fee.
 		// We generally don't care too much if they set the feerate to something very high, but it
 		// could result in the channel being useless due to everything being dust. This doesn't
 		// apply to channels supporting anchor outputs since HTLC transactions are pre-signed with a
 		// zero fee, so their fee is no longer considered to determine dust limits.
 		if !channel_type.supports_anchors_zero_fee_htlc_tx() {
-			let upper_limit = cmp::max(250 * 25,
-				fee_estimator.bounded_sat_per_1000_weight(ConfirmationTarget::HighPriority) as u64 * 10);
+			let upper_limit = fee_estimator.bounded_max_counterparty_selected_feerate();
 			if feerate_per_kw as u64 > upper_limit {
 				return Err(ChannelError::Close(format!("Peer's feerate much too high. Actual: {}. Our expected upper limit: {}", feerate_per_kw, upper_limit)));
 			}