splice: lightningd updates scid too early

[ddustin]

lightningd updates the channel's scid when a splice is confirmed on chain. This creates a subtle issue however where lightningd and channeld disagree on the scid for a short period of time.

After the splice is confirmed, channeld sends splice_locked and waits to hear it back. Once it is both sent and received it is considered mutual_splice_locked and will update the scid to its new post-splice value at that point.

If a disconnection and / or restart occurs after confirmation but before mutual_splice_locked, lightningd's new scid value will prevail incorrectly.

The primary fix is to move lightningd's scid update to occur after mutual_splice_lock instead, but this introduces new state complexity:

• On boot if splice is confirmed but not mutual_splice_locked, channeld_init should pass in values for splice_state->short_channel_id and splice_state->locked_txid.
• If channeld sees these values present in channeld_init, it should know the splice is confirmed but not locked. After reestablish is completed, it should begin the splice_locked procedure.
• Upon reestablish if the peer is using the stale scid, we should be okay with it but expect splice_locked within some kind of grace period.
• If we receive splice_locked but from our perspective we are already mutual_splice_locked, we should mirror the message back but not reemit any local mutal lock events

reference for discovery of the issue here: https://github.com/ElementsProject/lightning/pull/6628/files#issuecomment-1729967338