Don't trim HTLCs when calculating the fee spike commit tx fee

We previously accounted for HTLC trims at the spiked feerate when
calculating the commitment transaction fee including the fee spike
multiple.

This only ensured that the funder of the channel could afford the
commitment transaction fee for an exact 2x increase in the feerate.

Now, we check that the funder can cover any increase in the feerate
between 1x to 2x.

Author: tankyleo

lightning/src/sign/tx_builder.rs

@@ -301,9 +301,18 @@ fn get_next_commitment_stats(
 	// 2) Now including any additional non-dust HTLCs (usually the fee spike buffer HTLC), does the funder cover
 	// this bigger transaction fee ? The funder can dip below their dust limit to cover this case, as the
 	// commitment will have at least one output: the non-dust fee spike buffer HTLC offered by the counterparty.
+	let nondust_htlc_count = next_commitment_htlcs
+		.iter()
+		.filter(|htlc| {
+			!htlc.is_dust(local, feerate_per_kw, broadcaster_dust_limit_satoshis, channel_type)
+		})
+		.count();
+	// Note here we use the htlc count at the current feerate together with the spiked feerate;
+	// this makes sure that the holder can afford any fee bump between 1x to 2x from the current
+	// feerate if the fee spike multiple is included.
 	let commit_tx_fee_sat = commit_tx_fee_sat(
 		spiked_feerate,
-		spiked_nondust_htlc_count + addl_nondust_htlc_count,
+		nondust_htlc_count + addl_nondust_htlc_count,
 		channel_type,
 	);
 	let (holder_balance_msat, counterparty_balance_msat) = checked_sub_from_funder(