Update next_commitment_number logic for channel_reestablish

The splicing spec updates the logic pertaining to next_commitment_number
when sending a channel_reestablish message. Specifically:

The sending node:
  - if it has sent `commitment_signed` for an interactive transaction construction but
    it has not received `tx_signatures`:
    - MUST set `next_funding_txid` to the txid of that interactive transaction.
    - if it has not received `commitment_signed` for that interactive transaction:
      - MUST set `next_commitment_number` to the commitment number of the `commitment_signed` it sent.

Author: jkczyz

lightning/src/ln/channel.rs

@@ -10506,6 +10506,25 @@ where
 		self.sign_channel_announcement(node_signer, announcement).ok()
 	}
 
+	fn get_next_local_commitment_number(&self) -> u64 {
+		// The sending node:
+		//   - if it has sent `commitment_signed` for an interactive transaction construction but
+		//     it has not received `tx_signatures`:
+		//     - MUST set `next_funding_txid` to the txid of that interactive transaction.
+		//     - if it has not received `commitment_signed` for that interactive transaction:
+		//       - MUST set `next_commitment_number` to the commitment number of the `commitment_signed` it sent.
+		if let Some(session) = &self.interactive_tx_signing_session {
+			if !self.context.channel_state.is_their_tx_signatures_sent()
+				&& !session.has_received_commitment_signed()
+			{
+				return INITIAL_COMMITMENT_NUMBER
+					- self.holder_commitment_point.current_transaction_number();
+			}
+		}
+
+		INITIAL_COMMITMENT_NUMBER - self.holder_commitment_point.next_transaction_number()
+	}
+
 	#[rustfmt::skip]
 	fn maybe_get_next_funding_txid(&self) -> Option<Txid> {
 		// If we've sent `commtiment_signed` for an interactively constructed transaction
@@ -10581,7 +10600,7 @@ where
 
 			// next_local_commitment_number is the next commitment_signed number we expect to
 			// receive (indicating if they need to resend one that we missed).
-			next_local_commitment_number: INITIAL_COMMITMENT_NUMBER - self.holder_commitment_point.next_transaction_number(),
+			next_local_commitment_number: self.get_next_local_commitment_number(),
 			// We have to set next_remote_commitment_number to the next revoke_and_ack we expect to
 			// receive, however we track it by the next commitment number for a remote transaction
 			// (which is one further, as they always revoke previous commitment transaction, not