AsyncPaymentsMessageHandler trait for OnionMessenger

Add a trait for handling async payments messages to OnionMessenger. This allows
users to either provide their own custom handling for async payments messages
or rely on a version provided by LDK.

Onion message payload for async payments

Async payments uses onion messages to indicate when HTLCs are held and
released. Add these types along with the necessary parsing and encoding.

ser_macros: support messages with no fields

Merge pull request #3102 from tnull/2024-06-rustfmt-fuzz

`rustfmt`: Reformat the `fuzz` dir

Merge pull request #3098 from arik-so/arik/gossip-v2-parsing

Parse v2 gossip

Merge pull request #3078 from jkczyz/2024-05-invoice-event

Asynchronous `Bolt12Invoice` payment

Update documentation.

Parse v2 gossip.

Add pays_bolt12_invoice_asynchronously test

Expose send_payment_for_bolt12_invoice

UserConfig::manually_handle_bolt12_invoices allows deferring payment of
BOLT12 invoices by generating Event::InvoiceReceived. Expose
ChannelManager::send_payment_for_bolt12_invoice to allow users to pay
the Bolt12Invoice included in the event. While the event contains the
PaymentId for reference, that parameter is now removed from the method
in favor of extracting the PaymentId from the invoice's payer_metadata.

Reformat and tick config docs

Add UserConfig::manually_handle_bolt12_invoices

BOLT12 invoices are automatically paid once they have been verified.
Users may want to manually pay them by first performing additional
checks. Add a manually_handle_bolt12_invoices configuration option that
when set generates an Event::InvoiceReceived instead of paying the
invoice.

Merge pull request #3082 from valentinewallace/2024-04-bolt12-keysend-invoice

BOLT 12 static invoice encoding and building

Merge pull request #3103 from TheBlueMatt/2024-06-real-bench

Use a real (probing-generated) scorer in benchmarks

Static invoice parsing tests

Static invoice building tests

Builder for creating static invoices from offers

Add a builder for creating static invoices for an offer. Building produces a
semantically valid static invoice for the offer, which can then be signed with
the key associated with the offer's signing pubkey.

Add an InvoiceReceived event

Some users may want to handle a Bolt12Invoice asynchronously, either in
a different process or by first performing additional verification
before paying the invoice. Add an InvoiceReceived event to facilitate
this.

`rustfmt`: `fuzz/src/full_stack.rs`

Prepare `fuzz/src/full_stack.rs` for `rustfmt`

`rustfmt`: `fuzz/src/chanmon_consistency.rs`

Introduce `noret` wrappers

Drop unnecessary key derivation in route tests

In our route tests we need some "random" bytes for the router to
randomize amounts using. We generate this by building an actual
`KeysManager` and then deriving some random bytes using the
`EntropySource` trait. However, `get_route` (what we're normally
testing) doesn't actually use the random bytes, and even if it did,
using a `KeysManager` is just a fancy way of creating a constant,
so there's really no reason to do all the fancy crypto.

Instead, here, we change our routing tests and benchmarks to simply
use `[42; 32]` as the "random" bytes.

Push the route benchmark results into a separate uninlined function

This ensures the route benchmarks themselves will appear with a
distinct callgraph, making router profiling somewhat easier.

Use a real (probing-generated) scorer in benchmarks

Until now, our routing benchmarks used a synthetic scorer,
generated by scoring random paths to build up some history. This is
pretty far removed from real-world routing conditions, as
alternative paths generally have no scoring information and even
the paths we do take have only one or two past scoring results.

Instead, we fetch a static serialized scorer, generated using
minutely probes. This means future changes to the scorer's data may
be harder to benchmark, but makes for substantially more realistic
benchmarks for changes which don't impact the serialized state.

Static invoice encoding and parsing

Define an interface for BOLT 12 static invoice messages. The underlying
format consists of the original bytes and the parsed contents.

The bytes are later needed for serialization. This is because it must
mirror all the offer TLV records, including unknown ones, which aren't
represented in the contents.

Invoices may be created from an offer.

Merge pull request #3116 from TheBlueMatt/2024-06-3107-nit

Clarify `Display` text for `ClosureReason::HolderForceClosed` some

Prepare `chanmon_consistency.rs` for `rustfmt`

Merge pull request #3113 from TheBlueMatt/2024-04-async-monitor-fuzz

Fuzz reloading with a stale monitor in chanmon_consistency

Unblock channels awaiting monitor update based on `ChanMan` queue

When we have `ChannelMonitorUpdate`s which are completing both
synchronously and asynchronously, we need to consider a channel as
unblocked based on the `ChannelManager` monitor update queue,
rather than by checking the `update_id`s.

Consider the case where a channel is updated, leading to a
`ChannelMonitorUpdate` which completes asynchronously. The update
completes, but prior to the `ChannelManager` receiving the
`MonitorEvent::Completed` it generates a further
`ChannelMonitorUpdate`. This second update completes synchronously.
As a result, when the `MonitorEvent` is processed, the event's
`monitor_update_id` is the first update, but there are no updates
queued and the channel should be free to return to be unblocked.

Here we fix this by looking only at the `ChannelManager` update
queue, rather than the update_id of the `MonitorEvent`.

While we don't anticipate many users having both synchronous and
asynchronous persists in the same application, there isn't much
cost to supporting it, which we do here.

Found by the chanmon_consistency target.

Fuzz reloading with a stale monitor in chanmon_consistency

Now that we are gearing up to support fully async monitor storage,
we really need to fuzz monitor updates not completing before a
reload, which we do here in the `chanmon_consistency` fuzzer.

While there are more parts to async monitor updating that we need
to fuzz, this at least gets us started by having basic async
restart cases handled. In the future, we should extend this to make
sure some basic properties (eg claim/balance consistency) remain
true through `chanmon_consistency` runs.

InvoiceTlvStream{Ref}: add message_paths field

Will be used in static invoices. Also test that we'll fail to decode if these
paths are included in single-use BOLT 12 invoices.

Clarify `Display` text for `ClosureReason::HolderForceClosed` some

... to make it clear that we elected not to broadcast, rather than
failed to broadcast.

Merge pull request #3107 from mhrheaume/mhr/closure_reason_abandoned

Updated `ClosureReason::HolderForceClosed` with whether txn was broadcasted.

Use ? instead of matching in BOLT 12 invoice parsing.

Minor cleanup to be more concise.

BOLT 12 invoice: extract helper for invoice signing pubkey checks

Will be useful for static invoices.

BOLT 12 invoice: expose common helper methods and fields

Useful for static invoice support.

Genericize BOLT 12 invoice{_builder} common macro docs over invoice type

Will be useful so the docs generated work for static invoices.

Implement Readable for Responder

A future InvoiceReceived event will include a Responder. Since Event
implements Readable, so must Responder.

Implement Readable for Bolt12Invoice

A future InvoiceReceived event will include a Bolt12Invoice. Since Event
implements Readable, so must Bolt12Invoice.

Re-order imports in events module

Clean up invoice handling result logic

Use implicit returns from match expressions

Merge pull request #3037 from TheBlueMatt/2024-05-close-on-stale-fees

Force-close channels if their feerate gets stale without any update

Merge pull request #3086 from alecchendev/2024-05-holder-commitment

Add `HolderCommitmentPoint` struct to track commitment points

Get per commitment point everywhere else with HolderCommitmentPoint

This includes when building TxCreationKeys, as well as for open_channel
and accept_channel messages. Note: this is only for places where we are
retrieving the current per commitment point, which excludes
channel_reestablish.

Get per commitment point for channel ready using HolderCommitmentPoint

Updated `ClosureReason::HolderForceClosed` with broadcasted txn.

Use HolderCommitmentPoint for commitment number

Add HolderCommitmentPoint struct to ChannelContext

Add a test of stale-feerate-force-closure behavior

Force-close channels if their feerate gets stale without any update

For quite some time, LDK has force-closed channels if the peer
sends us a feerate update which is below our `FeeEstimator`'s
concept of a channel lower-bound. This is intended to ensure that
channel feerates are always sufficient to get our commitment
transaction confirmed on-chain if we do need to force-close.

However, we've never checked our channel feerate regularly - if a
peer is offline (or just uninterested in updating the channel
feerate) and the prevailing feerates on-chain go up, we'll simply
ignore it and allow our commitment transaction to sit around with a
feerate too low to get confirmed.

Here we rectify this oversight by force-closing channels with stale
feerates, checking after each block. However, because fee
estimators are often buggy and force-closures piss off users, we
only do so rather conservatively. Specifically, we only force-close
if a channel's feerate is below the minimum `FeeEstimator`-provided
minimum across the last day.

Further, because fee estimators are often especially buggy on
startup (and because peers haven't had a chance to update the
channel feerates yet), we don't force-close channels until we have
a full day of feerate lower-bound history.

This should reduce the incidence of force-closures substantially,
but it is expected this will still increase force-closures somewhat
substantially depending on the users' `FeeEstimator`.

Fixes #993

Skip fee reads in `full_stack_target` when connecting many blocks

When we connect 100 blocks in a row, requiring the fuzz input to
contain 100 fee estimator results is uneccessary, so add a bool
that lets us skip those reads.

Add a new `ClosureReason::PeerFeerateTooLow`

Closure due to feerate disagreements are a specific closure reason
which admins can understand and tune their config (in the form of
their `FeeEstimator`) to avoid, so having a separate
`ClosureReason` for it is useful.

Allow `ChannelError` to specify the `ClosureReason`

This will allow us to add more granular failure reasons when
returning the general `ChannelError::Close`.

Use `ChannelError::close` constructor when building a close variant

In the next commit we'll add a second field to
`ChannelError::Close` so here we prep by converting existing calls
to the constructor function, which is almost a full-file sed.

Add `ChannelError::close` constructor

Merge pull request #3101 from tnull/2024-06-fix-tx-sync

tx-sync: Make confirmables `Deref` and run `rustfmt`

Merge pull request #3111 from tnull/2024-06-rustfmt-fuzz-the-easy-part

`rustfmt`: Reformat the `fuzz` dir – the easy part

Merge pull request #3083 from valentinewallace/2024-05-ignore-onion-err-chan-upd

Ignore channel updates in onion errors

Still ignore `fuzz/src/lib.rs` for now

`rustfmt`: `src/zbase32.rs`

`rustfmt`: `src/utils/*`

`rustfmt`: `fuzz/src/router.rs`

`rustfmt`: `fuzz/src/refund_deser.rs`

`rustfmt`: `fuzz/src/process_network_graph.rs`

`rustfmt`: `fuzz/src/peer_crypt.rs`

`rustfmt`: `fuzz/src/offer_deser.rs`

`rustfmt`: `fuzz/src/offer_deser.rs`

`rustfmt`: `fuzz/src/msg_targets/*`

`rustfmt`: `fuzz/src/lib.rs`

`rustfmt`: `fuzz/src/invoice*.rs`

`rustfmt`: `fuzz/src/indexedmap.rs`

`rustfmt`: `fuzz/src/fromstr_to_netaddress.rs`

`rustfmt`: `fuzz/src/chanmon_deser.rs`

`rustfmt`: `fuzz/src/bin/*`

`rustfmt`: `fuzz/src/bech32_parse.rs`

`rustfmt`: `fuzz/src/base32.rs`

Add `rustfmt::skip` to the target template

Add `rustfmt::skip` to the `msg_target` template

Merge pull request #3080 from jkczyz/2024-05-compact-blinded-path-creation-trait

Optional compact blinded path creation

Merge pull request #3096 from alecchendev/2024-06-drop-one-signer-call

Cache commitment point on ExternalHTLCClaim to drop a signer call

Merge pull request #3105 from johncantrell97/johncantrell97/add-peer-dis/connected-to-cmh

add peer_(dis)connected to custom message handler

Pass our `edition` to `rustfmt`

.. as it otherwise doesn't seem to pick up the right one when checkin
integration tests.

`rustfmt`: `lightning-transaction-sync/tests/integration_tests.rs`

add peer_(dis)connected to custom message handler

`rustfmt`: Reformat `lightning-transaction-sync/src/lib.rs`

`rustfmt`: Reformat `lightning-transaction-sync/src/error.rs`

`rustfmt`: Reformat `lightning-transaction-sync/src/esplora.rs`

`rustfmt`: Reformat `lightning-transaction-sync/src/electrum.rs`

`rustfmt`: Reformat `lightning-transaction-sync/src/common.rs`

Make `confirmables` `Deref`

.. the bindings branch needed a small patch as it doesn't support `dyn`
traits. Here, we opt to use `Deref` in the hopes this works with
bindings, rendering the patch unnecessary.

Clarify docs regarding one-hop blinded paths

The docs assumed ChannelManager is parameterized by DefaultRouter, which
may not be the case. Clarify the behavior is specific to using
DefaultRouter.

Exclude disconnected peers from BlindedPath

When calling MessageRouter::create_blinded_path, ChannelManager was
including disconnected peers. Filter peers such that only connected ones
are included. Otherwise, the resulting BlindedPath may not work.

Fix functional_test_utils::reconnect_nodes

When reconnecting nodes, make sure to notify OnionMessenger that the
nodes are now connected.

Use compact blinded paths for short-lived offers

When an offer is short-lived, the likelihood of a channel used in a
compact blinded path going away is low. Require passing the absolute
expiry of an offer to ChannelManager::create_offer_builder so that it
can be used to determine whether or not compact blinded path should be
used.

Use the same criteria for creating blinded paths for refunds as well.

Don't use compact blinded paths for reply paths

There's no need to save space when creating reply paths since they are
part of onion messages rather than in QR codes. Use normal blinded paths
for these instead as they are less likely to become invalid in case of
channel closure.

Refactor MessageRouter::create_blinded_paths

Using compact blinded paths isn't always necessary or desirable. For
instance, reply paths are communicated via onion messages where space
isn't a premium unlike in QR codes. Additionally, long-lived paths could
become invalid if the channel associated with the SCID is closed.
Refactor MessageRouter::create_blinded_paths into two methods: one for
compact blinded paths and one for normal blinded paths.

Move DefaultMessageRouter::create_blinded_paths

An upcoming change to the MessageRouter trait will require reusing
DefaultMessageRouter::create_blinded_paths. Move the code to a utility
function so facilitate this.

Merge pull request #3072 from arik-so/arik/gossip-v2-parsing

Reintroduce addresses to NodeAnnouncementInfo.