rust-lightning

Enforce that `ChanelSigner::pubkeys` is only called once

In the previous commit we partially reverted
9d291e01f98417c2f6b2d4321bbf806464c424a6 renaming
`ChannelSigner::new_pubkeys` to `pubkeys` again, but we still don't
want to go back to requiring that `pubkeys` return the same
contents on each call. Thus, here, we add test logic to check that
`pubkeys` isn't called more than once.

Add `rust-version` to all crates' `Cargo.toml`s

Drop `AddSigned` trait

.. now that we can, addressing a TODO.

Drop unused fields from `lightning-transaction-sync` test utils

Bump MSRV to rustc 1.75.0

We generally align our MSRV with Debian's stable channel. Debian 13
'Trixie' was just released, shipping rustc 1.85. However, as 1.85.0 is
only about ~7months old at this point, we opt to bump to the more
conservative 1.75.0, which approaches two years of age.

Capture stfu send in reconnection tests

We'll use this in the next commit to test that we'll send a stfu message
for a splice we intend to initiate upon reconnecting.

Replace docs.rs build `doc_auto_cfg` feature with `doc_cfg`

These have been merged, causing our docs.rs builds to fail. Sadly,
we saw our docs.rs build fail for the 0.1.6 upload because of this.

Correct name of `get_counterparty_payment_script` method

`get_counterparty_payment_script` fetches the countersigner's (i.e.
non-broadcaster) payment script, but that could be ours or or
counterparty's. Thus, it should read
`get_countersigner_payment_script`, which we fix here.

Add a method to fetch all possible remote-closure `script_pubkey`s

In the previous commit we (finally) allowed users to opt into a
static `remote_key` derivation scheme, enabling them to scan the
chain for funds on counterparty commitment transactions without any
state at all.

This is only possible, however, of course, if they have the full
list of scripts to scan the chain for, which we expose here.

Test channel reestablish during splice lifecycle

This test captures all the new spec requirements introduced for a splice
to the channel reestablish flow.

Give the `get_change_destination_script` future access to `self`

Its generally useful for trait methods to be able to access `self`,
sadly our definition of `get_change_destination_script` was screwed
up and couldn't. Luckily its an easy fix as none of the callsites
care about the extra `self` lifetime.

Support client_trusts_lsp on LSPS2

Allow passing an `OutputSweeperSync` to the sync-KVStore-async-BP

`OutputSweeper::new_with_kv_store_sync` is a pretty strange API -
it allows building an async `OutputSweeper` where the only `await`s
are on a sync `KVStore`, ie will immediately block until the IO
operation completes.

While this isn't broken (futures are allowed to take their time,
and async runtimes have to handle this, though they often don't
handle it particularly well), its pretty weird. It seems to exist
largely for `process_events_async_with_kv_store_sync`, which does
async `Event` handling but sync `KVStore` operations (like the
existing pre-0.2 "async" background processor).

Instead, we allow passing an `OutputSweeperSync` to
`process_events_async_with_kv_store_sync`, keeping the API
consistent such that a user would use the appropriate
`OutputSweeper` variant, but fetching the inner async
`OutputSweeper` inside the BP.

Fix race condition causing async payment failure

As the LSP of an async sender, when we receive an update_add with the hold_htlc
flag set, after its onion is decoded we transition the pending HTLC to the
ChannelManager::pending_intercepted_htlcs. However, if we receive the
release_held_htlc message from the receiver *before* we've had a chance to make
this transition, we'll fail to release the HTLC and it will sit in the pending
intercepts map until it is failed backwards.

To fix this race condition, if we receive release_held_htlc from the recipient
we'll not only check the pending_intercepted_htlcs map for the presence of this
HTLC but also check the map where we keep HTLCs prior to their onions being
decoded.

Add `test_p2a_anchor_values_under_trims_and_rounds`

Adjust the weight of htlc success and timeout witnesses in 0FC channels

Relax feerate requirements in `TxBuilder::get_next_commitment_stats`

We sometimes do not have easy access to the
`dust_exposure_limiting_feerate`, yet we are still interested in basic
stats on commitments like balances and transaction fees. So we relax
the requirement that the `dust_exposure_limiting_feerate` is always set
when `feerate_per_kw` is not 0.

Cleanup dust exposure due to excess fees in `get_next_commitment_stats`

Make `TxBuilder::get_next_commitment_stats` fallible

Anytime we ask `TxBuilder` for stats on a commitment transaction,
`TxBuilder` can now return an error to indicate that a balance not
including the commitment transaction fee has been overdrawn. We then
map this error to the appropriate action depending on where in the
life cycle of the channel the error occurred.

We now do not require that `channel_value_satoshis * 1000` is greater
than or equal to `value_to_holder_msat`; we previously would panic
in this case.

Marginally simplify `TestStore`

Correct `maximum_pending_updates` of 0 in MonitorUpdatingPersister

Though users maybe shouldn't use `MonitorUpdatingPersister` if they
don't actually want to persist `ChannelMonitorUpdate`s, we also
shouldn't panic if `maximum_pending_updates` is set to zero.

Set HTLC tx version 3 on handling `BumpTransactionEvent::HTLCResolution`

Add forwards-compatibility logic in `LocalHTLCFailureReason` ser

We recently created a `LocalHTLCFailureReason` enum to cover
detailed reasons why an HTLC may have failed, in excess of the
on-the-wire failure encoding.

Sadly, when we did so we introduced a serialization format which
isn't particularly conducive to introducing new failure reasons in
the future. Luckily, `LocalHTLCFailureReason` already has logic
that works for forwards-compatibility - it can be converted to, and
from, the on-the-wire error codes.

Thus, here, we take advantage of that, writing both the on-the-wire
error code as well as a code for the specific case. If we don't
recognize the specific case on deserialization, we'll fall back to
the default case for the on-the-wire code we've written.

We also, of course, include a length-prefixed TLV stream to allow
for additional fields in the future.

Fixes #4087

Fix lint CI job

Actually remove forward<>intercepted htlcs lock dep

8513341b1f7c39da3e6ad4521d4161362b0f4562 purported to remove a lock dependency
between ChannelManager::pending_intercepted_htlcs and ::forward_htlcs. However,
in practice the dependency remained because the locks of the two maps were
still held at the same time in some cases. Here we fix this.