Eclair

Simple taproot channels (#3103)

Implement simple taproot channels

We add new commitment formats and TLV extensions to include musig2 nonces. This includes a specific commitment format for phoenix
taproot channels.

The old v1 channel establishment protocol is updated to include nonces and partial signatures.

The v2 channel estalishment protocol, based on the interactive tx constuction protocol, is also updated, and the
interactive tx session now includes:
- an optional funding nonce for the shared input (i.e. the funding tx that is being spent)
- a nonce for the commit tx that is being created, and another nonce that will become the channel's "next remote nonce" once the session completes
The funding nonce is random and its lifecycle is bound to the interactive session.

Side note: the new v2 protocol is both simpler to extend and gives us support for dual-funding and splices.

Since there can be several different commitment transactions that valid at the same time while splices are pending, revoke_and_ack
and channel_restablish are extended to include a list of funding_tx_id -> nonce tuples (one for each active commitment).

channel_restablish also includes as an optional "current commit nonce": if we got disconnected while a splice was in progress
before both nodes exchanged their commit signatures: if that is the case, we need to re-send our peer's current signature
and will use this nonce to compute it.

We also update the simple close protocol to include closing nonces.

We allow upgrading channels to taproot during splices, with an optional channel_type TLV added to splice_init/splice_ack.
This is not part of the BOLT proposal, and upgrading is currently limited to phoenix taproot channels from phoenix anchor channels.

Extract `CommitParams` to individual commitments (#3118)

We introduce a new channel codec version where:

- we extract per-commitment parameters (commitment format and params
such as `dust_limit` which we may want to dynamically update in the
future)
- we clean-up the splice iterations on the `Commitments` structure
- we remove the funding transaction from the confirmed local funding
status (once confirmed, we don't need it anymore: it is wasting DB
space for no good reason, we can get it from the blockchain)
- we add a `maxClosingFeerate_opt` to the closing state, to allow
limiting the feerate used in RBF attempts for safe transactions
- we add the commitment format to interactive-tx parameters
- we make channel type feature non permanent

We add a mechanism to prevent the node from starting-up, unless an
override is provided. This provides an opportunity to iterate on codecs
while knowing that node operators won't be affected if we make changes
that are backwards-incompatible. This is meant to be temporary.

Offers with currency must set amount. (#3140)

Adds check and corresponding test from lightning/bolts#1279

Use actual CLTV delta for reputation (#3134)

When computing reputation, instead of using a fixed multiplier for pending HTLCs, we now use the CLTV expiry of the HTLC (assuming a new block is mined every 10 minutes).
The reason for the fixed multiplier was that a HTLC with the maximum CLTV delta could stay pending for several orders of magnitude longer than a regular HTLC and would have an oversized impact on the reputation. We mitigate this by increasing the expected settlement time (from a few seconds to a few minutes), using more historical data (increasing the half-life), and counting on the fact that most HTLCs will have a CLTV expiry a lot lower than the maximum.

Add recent invoice spec test vectors (#3137)

Add test vectors from https://github.com/lightning/bolts/pull/1276
and https://github.com/lightning/bolts/pull/1264