Implement `Readable` for `Bolt12Invoice`

In c13b6d814bfb5dd95f9e40f8ff07dd45c47a387e and
fc14495ac6a9dbe7dc9a6bd43c4395b599592db1 we implemented `Readable`
for `Refund` and `Offer`s, but didn't do so for `Bolt12Invoice`.

Because `Bolt12Invoice`s are not serializable to strings, we
generally expect users to read and write them as byte arrays, and
currently expose this via `TryFrom<Vec<u8>>`. This is fine, but
there's no reason to not implement `Readable` as well, and it
saves having to implement `TryFrom` in bindings.

Merge pull request #3125 from valentinewallace/2024-06-async-payments-prefactor

Async payments message encoding and prefactor

Cfg-gate async payments module and public enum variants.

Remove unused imports in static_invoice.rs

Add OffersMessage variant for static invoices.

DRY responder instantiation for onion messages.

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.

Merge pull request #2966 from G8XSU/2647-distribute

Optimize ChannelMonitor persistence on block connections.

Merge pull request #3127 from wvanlint/non_strict_forwarding

Implement non-strict forwarding

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.

Merge pull request #3135 from tnull/2024-06-rustfmt-rgs

Run `rustfmt` on `lightning-rapid-gossip-sync`

`rustfmt`: Drop `benches/src/bench.rs` from excluded files

`rustfmt`: Run on `lightning-rapid-gossip-sync/src/lib.rs`

`rustfmt`: Run on `lightning-rapid-gossip-sync/src/processing.rs`

`rustfmt`: Prepare `lightning-rapid-gossip-sync/src/processing.rs`

Implement non-strict forwarding

This change implements non-strict forwarding, allowing the node to
forward an HTLC along a channel other than the one specified
by short_channel_id in the onion message, so long as the receiver has
the same node public key intended by short_channel_id
([BOLT](https://github.com/lightning/bolts/blob/57ce4b1e05c996fa649f00dc13521f6d496a288f/04-onion-routing.md#non-strict-forwarding)).
This can improve payment reliability when there are multiple channels
with the same peer e.g. when outbound liquidity is replenished by
opening a new channel.

The implemented forwarding strategy now chooses the channel with the
lowest outbound liquidity that can forward an HTLC to maximize the
probability of being able to successfully forward a subsequent HTLC.

Fixes #1278.

Merge pull request #3132 from jkczyz/2024-06-bolt12-unannounced

Blinded paths with unannounced introduction nodes

Optimize ChannelMonitor persistence on block connections.

Currently, every block connection triggers the persistence of all
ChannelMonitors with an updated best_block. This approach poses
challenges for large node operators managing thousands of channels.
Furthermore, it leads to a thundering herd problem
(https://en.wikipedia.org/wiki/Thundering_herd_problem), overwhelming
the storage with simultaneous requests.

To address this issue, we now persist ChannelMonitors at a
regular cadence, spreading their persistence across blocks to
mitigate spikes in write operations.

Outcome: After doing this, Ldk's IO footprint should be reduced
by ~50 times. The processing time required to sync each block
will be significantly reduced, particularly for nodes with 1000s
of channels, as write latency plays a significant role in this process.
As a result, the Node/ChainMonitor will be blocked for a shorter
duration, leading to further efficiency gains.

Merge pull request #3126 from TheBlueMatt/2024-06-preimage-removal-blocked-by-claim-event

(Very) marginally expand `test_monitor_update_fail_claim`

(Very) marginally expand `test_monitor_update_fail_claim`

For some reason I wasn't sure this happened yet, so making the
test for no-`PaymentClaimed`-event-before-preimage-on-disk explicit
is nice.

Merge pull request #3115 from alecchendev/2024-06-specific-async-sign

Refactor async signing test utils to toggle specific method availability

Relax channel count check for unannounced nodes

When creating blinded paths, introduction nodes are limited to peers
with at least three channels to prevent easily guessing the recipient.
Relax this check when the recipient is unannounced since they won't be
in the NetworkGraph.

Advance self blinded payment paths

DefaultRouter will ignore blinded paths where the sender is the
introduction node. Similar to message paths, advance such paths by one
so that payments may be sent to them.

Re-order imports

Rename variable

Add advance_path_by_one for blinded payment paths

Similar to blinded paths for onion messages, if given a blinded payment
path where we are the introduction node, the path must be advanced by
one in order to use it.

Don't modify path when advance_path_by_one errors

When using advance_path_by_one when we are the introduction node, any
error will result having the first hop of the input blinded path
removed. Instead, only remove the first hop on success. Otherwise, the
path will be invalid.

Blinded payments to unannounced introduction node

When creating blinded paths for receiving onion payments, allow using
the recipient's only peer as the introduction node when the recipient is
unannounced. This allows for sending payments without going through an
intermediary, which is useful for testing or when only connected to an
LSP with an empty NetworkGraph.

BlindedPath with unannounced introduction node

When creating blinded paths for receiving onion messages, allow using
the recipient's only peer as the introduction node when the recipient is
unannounced. This allows for sending messages without going through an
intermediary, which is useful for testing or when only connected to an
LSP with an empty NetworkGraph.

Merge pull request #3130 from TheBlueMatt/2024-06-doc-fee-present

Document when `Events::PaymentSent::pending_fee_msat` is `Some`

Remove global availability logic for testing async signing

Refactor tests to use specific async signing ops

Allow toggling specific signing methods in test channel signer

Start tracking chain_sync_monitor_persistences in TestPersister

It is helpful to assert that chain-sync did trigger a monitor
persist.

Merge pull request #3128 from TheBlueMatt/2024-06-no-claim-ret

Drop unused return value from `claim_funds_from_hop`

Document when `Events::PaymentSent::pending_fee_msat` is `Some`

Merge pull request #3123 from dunxen/2024-06-channelrefactor

Move accept_channel checks into `ChannelContext::do_accept_channel_checks`

Drop unused return value from `claim_funds_from_hop`

Move accept_channel checks into `ChannelContext::do_accept_channel_checks`

This is done ahead of getting the dual-funding implementation to reduce
refactoring noise there.

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/*`