Reset the channel state before restarting the channel establishment p…

…rocess.

1. When our counterparty disconnects during channel creation, we could have
   progressed along the channel creation process.
2. In such cases, retrying to send the OpenChannel message would fail because
   the channel state had progressed, leading to a panic in the `get_open_channel`.
3. To prevent this issue, introduce a new function, `reset_channel_state`, which
   resets the channel state to its initial state and use it before regenerating
   the OpenChannel message for an Unfunded Outbound channel.

Fixes [lightningdevkit#2982](lightningdevkit#2982)

(Identified by the full_stack_target fuzzer)

lightning/src/ln/channel.rs

@@ -2123,6 +2123,10 @@ impl<SP: Deref> ChannelContext<SP> where SP::Target: SignerProvider  {
 		self.channel_state > ChannelState::NegotiatingFunding(NegotiatingFundingFlags::OUR_INIT_SENT)
 	}
 
+	pub(super) fn reset_state(&mut self) {
+		self.channel_state = ChannelState::NegotiatingFunding(NegotiatingFundingFlags::OUR_INIT_SENT);
+	}
+
 	/// Returns true if this channel is fully established and not known to be closing.
 	/// Allowed in any state (including after shutdown)
 	pub fn is_usable(&self) -> bool {

lightning/src/ln/channelmanager.rs

@@ -10084,6 +10084,10 @@ where
 						}
 
 						ChannelPhase::UnfundedOutboundV1(chan) => {
+							// Reset the channel state before resending the OpenChannel message.
+							// This step ensures that the channel is in its initial state before
+							// starting the channel establishment process.
+							chan.context.reset_state();
 							pending_msg_events.push(events::MessageSendEvent::SendOpenChannel {
 								node_id: chan.context.get_counterparty_node_id(),
 								msg: chan.get_open_channel(self.chain_hash),