Send channel_announcement for splice transactions on public channels

[t-bast]

We now support splicing on public channels: once the splice transaction is confirmed and locked on both sides, nodes will exchange announcement signatures that allows them to create a channel_announcement that they then broadcast to the network.

This requires reworking the data model to include the announcement and the real short_channel_id in each commitment, which lets us cleanly distinguish real short_channel_ids from aliases (which are set at the channel level regardless of the current commitments).

The flow now becomes:

• when the funding transaction of a commitment confirms, we set the corresponding real short_channel_id in that commitment
• if the channel is public and we've received channel_ready or splice_locked, we send our announcement_signatures
• if we receive announcement_signatures for a commitment for which the funding transaction is unconfirmed, we stash it and replay it when the transaction confirms
• if we receive announcement_signatures for a confirmed commitment, and we don't have a more recently announced commitment, we generate a channel_announcement, store it with the commitment and update our router data

When creating a channel_update for a public channel, we always use the short_channel_id that matches the latest announcement we created. This is very important to guarantee that nodes receiving our updates will not discard them because they cannot match it to a channel.

For private channels, we stop allowing usage of the short_channel_id for routing: scid_alias MUST be used, which ensures that the channel utxo isn't revealed.

Note that when migrating to taproot channels, splice_locked will be used to transmit nonces for the announcement signatures, which will be compatible with the existing flow (and similarly, channel_ready will be used for the initial funding transaction). They are retransmitted on reconnection to ensure that the announcements can be generated.

Don't be scared by the large number of added lines: most of them are JSONs for backwards-compatibility serialization tests.

[t-bast]

Important note: for channels encoded with v3 or lower, we don't add any migration code, so it looks like we're losing information about the real short_channel_id, but that isn't the case: since we set localFundingStatus to unconfirmed (in ChannelTypes0.scala and ChannelTypes3.scala), we will set a WatchFundingConfirmed when restarting which lets us obtain details about the funding transaction and correctly set the short_channel_id.

[remyers]

I've taken a first pass and it looks good so far. I've focused mostly on the channel and router behavior; less on the serialization so far.

During a channel reestablishment it seems like we only resend announcement sigs when no announcement was sent during initial funding, but not during splices.

I also have a few questions and suggestions to add tests for a few incidental bug fixes you made during the refactor that probably don't have associated tests.

[remyers]

The serialization code looks pretty straight forward for the most part. I do have one suggestion and found one potential issue related to moving the real scid to the funding status.

The merge-base changed after approval.