rust-lightning

Miscellanous CI fixes

Update handling of `BumpTransactionEvent::ChannelClose` for 0FC channels

Set an empty witness to spend the P2A anchor, and set the version of the
anchor transaction to 3.

We still check whether the commitment transaction has enough fees to be
broadcast on its own, as these transactions may be non-zero fee due to
trimmed / rounded outputs.

Set `AnchorDescriptor` output value to CSV and P2A anchor amounts

Co-authored-by: Matt Corallo <git@bluematt.me>

Use correct nonce in InvoiceRequest context

Previously it would generate a new nonce for this context
instead of using the offer nonce. This would make it so
that verification would fail later when receiving a
invoice request.

Inline promote_splice_funding macro

Remove forward_htlcs<>intercepted_htlcs lock dep

We previously had a lock order dependency where the forward_htlcs lock had to
be taken before the intercepted_htlcs lock. Here we remove this dependency,
which also prepares for a cleaner commit once we start also intercepting HTLCs
for often-offline recipients.

Remove stale TODO for quiescence check on incoming splice_init

Rename `CommitmentTransaction.feerate_per_kw()`

Use `negotiated_feerate_per_kw()` to underscore that this is the feerate
we negotiated with our peer, not the actual feerate of the commitment
transaction. The feerate of the actual commitment transaction may be
higher.

Serialization for Vec<BlindedMessagePath>

Add a method to avoid re-persisting monitors during startup

Prior to LDK 0.1, in rare cases we could replay payment claims to
`ChannelMonitor`s on startup, which we then expected to be
persisted prior to normal node operation. This required
re-persisting `ChannelMonitor`s after deserializing the
`ChannelManager`, delaying startup in some cases substantially.

In 0.1 we fixed this, moving claim replays to the background to run
after the `ChannelManager` starts operating (and only
updating/persisting changes to the `ChannelMonitor`s which need
it). However, we didn't actually enable this meaningfully in our
API - nearly all users use our `ChainMonitor` and the only way to
get a chanel into `ChainMonitor` is through the normal flow which
expects to persist.

Here we add a simple method to load `ChannelMonitor`s into the
`ChainMonitor` without persisting them.

Check v2 reserves after `funding_contribution_satoshis` is applied

We check this when validating `splice_init`, `splice_ack` messages, and
also when validating user-specified contributions.

From BOLT 2:
```
- If `funding_contribution_satoshis` is negative and its absolute value
is greater than the sending node's current channel balance:
- MUST send a `warning` and close the connection or send an `error`
and fail the channel.
```

and further down:
```
If a side does not meet the reserve requirements, that's OK: but if they
take funds out of the channel, they must ensure that they do meet them.
If your peer adds a massive amount to the channel, then you only have
to add more reserve if you want to contribute to the splice (and you
can use `tx_remove_output` and/or `tx_remove_input` part-way through if
this happens).
```

Therefore, we check the v2 reserve anytime
`funding_contribution_satoshis` is not equal to zero.

We allow parties to draw from their previous reserve, as long as they
satisfy their v2 reserve.

Make `for_splice` infallible

Add `NextCommitmentStats::get_balances_including_fee`

`NextCommitmentStats` provides the commitment transaction fee as a
separate value to assist with applying a multiplier on it in
`can_accept_incoming_htlc`.

Nonetheless in most cases, we want the balances to include the
commitment transaction fee, so here we add a helper that gives us these
balances.

Also make the style of `tx_builder::subtract_addl_outputs` consistent
with `get_balances_including_fee`.

Rustfmt Channel::get_last_revoke_and_ack

Push splice initiation through the quiescent pipeline

Now that we have a `QuiescentAction` to track what we intend to do
once we reach quiescence, we need to use it to initiate splices.

Here we do so, adding a new `SpliceInstructions` to track the
arguments that are currently passed to `splice_channel`. While
these may not be exactly the right arguments to track in the end,
a lot of the splice logic is still in flight, so we can worry about
it later.

Add a quick TODO about merging cp- and locally-initiated splices

Run fmt on `validate_update_fee`

Run fmt on `can_send_update_fee`

Run fmt on `can_accept_incoming_htlc`

Run fmt on `validate_update_add_htlc`

Run fmt on `get_next_commitment_htlcs`

Remove all `rustfmt::skip` in `tx_builder`

Add `TxBuilder::get_next_commitment_stats`

Given a snapshot of the lightning state machine,
`TxBuilder::get_next_commitment_stats` calculates the transaction fees,
the dust exposure, and the holder and counterparty balances
(the balances themselves do *not* account for the transaction fee).

Adjust dust exposure due to excess fees for clarity

Remove #[rustfmt] from test_peer_storage