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 they won't understand the even TLV field.

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

@ddustin you should be able to start cross-compat tests based on this branch.

NB: builds on top of #2968

[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.

[t-bast]

Rebased to include changes linked to liquidity ads and on-the-fly funding.

Some on-the-fly funding tests aren't passing anymore, because it's harder to make eclair mimick the behavior of a wallet that doesn't contribute at all to funding transactions: we'll need to re-work those tests, I'm not sure yet what exactly will be best.

We will probably integrate the second and third commits independently, once we're confident Phoenix users all support quiescence. This should help us integrate this bit by bit and make sure test coverage is good enough.