Revert HTLC transactions in 0FC channels back to Version::TWO

Otherwise, we could potentially hit the max 10_000vB size limit on V3
transactions (BIP 431 rule 4) if we aggregate enough HTLC-claims
together.

For now in 0FC channels, we do not aggregate HTLC-claims with the
P2A-anchor-claim, and wait for the commitment transaction to be fully
confirmed before broadcasting HTLC claims (which is the same behavior
as in keyed-anchor channels). There is hence no need for HTLC
transactions to be V3.

Note that the counterparty signature on the HTLC transaction *does*
commit to the version of the transaction.

Co-authored-by: Carla Kirk-Cohen <[email protected]>

Author: tankyleo

lightning/src/events/bump_transaction/mod.rs

@@ -855,11 +855,7 @@ where
 			.transaction_parameters
 			.channel_type_features;
 		let mut htlc_tx = Transaction {
-			version: if channel_type.supports_anchor_zero_fee_commitments() {
-				Version::non_standard(3)
-			} else {
-				Version::TWO
-			},
+			version: Version::TWO,
 			lock_time: tx_lock_time,
 			input: vec![],
 			output: vec![],

lightning/src/ln/chan_utils.rs

@@ -830,14 +830,8 @@ pub fn build_htlc_transaction(
 		revocation_key,
 	)];
 
-	let version = if channel_type_features.supports_anchor_zero_fee_commitments() {
-		Version::non_standard(3)
-	} else {
-		Version::TWO
-	};
-
 	Transaction {
-		version,
+		version: Version::TWO,
 		lock_time: LockTime::from_consensus(if htlc.offered { htlc.cltv_expiry } else { 0 }),
 		input: txins,
 		output: txouts,

lightning/src/ln/monitor_tests.rs

@@ -2889,7 +2889,7 @@ fn do_test_anchors_aggregated_revoked_htlc_tx(p2a_anchor: bool) {
 			}],
 		};
 		let mut htlc_tx = Transaction {
-			version: if p2a_anchor { Version::non_standard(3) } else { Version::TWO },
+			version: Version::TWO,
 			lock_time: LockTime::ZERO,
 			input: vec![TxIn { // Fee input
 				previous_output: bitcoin::OutPoint { txid: coinbase_tx.compute_txid(), vout: 0 },