Use final spec values for splicing

[t-bast]

We replace our experimental version of splice_init, splice_ack and splice_locked by their official version (see lightning/bolts#1160). If our peer is using the experimental feature bit, we convert our outgoing messages to use the experimental encoding and incoming messages to the official messages.

We also change the TLV fields added to tx_add_input, tx_signatures and splice_locked to match the spec version. We always write both the official and experimental TLV to updated nodes (because the experimental one is odd and will be ignored) but we drop the official TLV if our peer is using the experimental feature, because it won't understand the even TLV field.

This guarantees backwards-compatibility with peers who only support the experimental feature.

We also implement RBF support for splice transactions in the last commit: that's the part of this PR that really needs a thorough review. I can probably port some parts of this commit to master as preparatory steps if that makes it easier to review.

@ddustin you should be able to start cross-compat tests based on this branch. Note that we currently only support unannounced channels (we haven't implemented the gossip part yet).

Fixes #2781

[remyers]

This is an observation that occurred to me while reviewing this PR that might be relevant for a future PR ..

There will be times when using CMD_BUMP_FUNDING_FEE instead of CMD_SPLICE would cost less on-chain and confirm faster if you want to perform an additional splice while a pending splice is unconfirmed. The total cost to create a new funding transaction with CMD_SPLICE will often be higher than making the same changes with CMD_BUMP_FUNDING_FEE at a slightly higher fee rate. If you are blocked from making a new splice because a pending splice has been fee bumped, you could also make a new fee bump to splice in/out value rather than waiting for the previously rbf'd splice to confirm.

This seems to be technically possible in the protocol because CMD_BUMP_FUNDING_FEE uses the interactive tx protocol and can change the funding contribution with the funding_output_contribution TLV. Figuring out if a splice or rbf-splice is cheaper will also need to consider the additional fees paid to bump our counter party's inputs and outputs.

Perhaps the biggest downside I can see (beside complexity) is that if your pending splice or rbf confirms before a rbf-splice, then you would need to renegotiate it as a new splice.

Am I missing something here wrt fee savings? Do you think it would be worth considering this situation now rather than later?

[t-bast]

Perhaps the biggest downside I can see (beside complexity) is that if your pending splice or rbf confirms before a rbf-splice, then you would need to renegotiate it as a new splice.

Yes, the main reason we're not providing this yet (even though this is in theory possible) is to manage complexity. It can get really complex very quickly once you start going down that road, because if each splice "part" maps to a specific action (e.g. an on-the-fly funding), it can be a huge mess to reconcile which parts where actually done and which parts need to be replayed if a previous RBF attempt confirms.

[remyers]

Looks good - the refactor for RBF makes it easier to read/understand.

I found a few nits but main issues to take a look at are related to adding logic to reject an TxInitRbf or SpliceInit when the parent splice is unconfirmed.

[remyers]

Changes to tests to disallow sequences of unconfirmed splices looks good. I only had a few minor nits/questions.

[remyers]

nit: is it important to pass WatchTxConfirmedTriggered to watchConfirmedCommit2.replyTo instead of just passing to alice as you do elsewhere?

[t-bast]

No, it was really useless, I'd rather keep it simple and easier to read by referring to alice and bob everywhere.