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.

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

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.

Cache commitment point on ExternalHTLCClaim to drop a signer call

Merge pull request #3095 from TheBlueMatt/2024-06-tx-sync-bindings-upstream

Mark BDK types exported from transaction-sync as no-export

Reintroduce addresses to NodeAnnouncementInfo.

Mark BDK types exported from transaction-sync as no-export

Merge pull request #3091 from TheBlueMatt/2024-06-channel_state_ser

Move serialization of `channel_state` fields to `channel_state.rs`

Merge pull request #3081 from G8XSU/2024-05-08-claimable-persist-3049-outputs

Watch all outputs irrespective of claimable outpoints

Fromat moved code in `channel_state.rs`

Move serialization of `channel_state` fields to `channel_state.rs`

1f616c0058f77e074c429fa7fb8b2f4594cdb9ad moved a handful of structs
to the new `channel_state.rs` but forgot to move their
serialization logic with them, which is corrected here.

Merge pull request #3060 from TheBlueMatt/2024-05-parallel-async-om-events

Add a parallel async event handler to OnionMessenger and pass it directly to BackgroundProcessor

Merge pull request #3088 from alecchendev/2024-06-fc-no-disconnect

Don't disconnect on manual force closes

Merge pull request #3089 from TheBlueMatt/2024-06-channel_state-module

Move the public channel state API into a new module

Move the public path for `channel_state` types to their new path

Reformat `channel_state.rs` to match rustfmt requirements

Move the public channel state API into a new module

Our "what is the channel's current state" structs have slowly
grown to be rather nontrivial, and now include eight structs with
many fields. Thus, it makes sense to pull them out of
`ln::channelmanager` and into their own module.

This also makes things easier for the C bindings which don't
support `pub use` from a private module.

Merge pull request #2965 from tnull/2024-03-impl-readable-writeable-offer-invoice-refund

Implement `Readable` for `Offer` and `Refund`

Implement `Readable` for `Refund`

When storing `Refund`s, it's useful for them to implement LDK's
deserialization trait.

Implement `Readable` for `Offer`

When storing `Offer`s, it's useful for them to implement LDK's
deserialization trait.

Don't disconnect on manual force closes

Merge pull request #2889 from Sharmalm/2840

Allow for user-specified error message during force close channel

Watch all outputs irrespective of claimable outpoints.

This removes dependency of watched_outputs from
per_commitment_claimable_outpoints, it is required since we will
no longer have direct access to per_commitment_claimable_outpoints
once we start publishing PersistClaimInfo as part of #3049.

Drop `EventsProvider` bounds on `OnionMessageHandler`s

This never really made a lot of sense from an API perspective, but
was required to avoid handing the background processor an explicit
`OnionMessegner`, which we are now doing. Thus, we can simply drop
these bounds as unnecessary.

f fix imports in BP

Switch to using the `OnionMessenger` directly in BP

When `OnionMessenger` first developed a timer and events interface,
we accessed the `OnionMessenger` indirectly via the `PeerManager`.
While this is a fairly awkward interface, it avoided a large pile
of generics on the background processor interfaces. However, since
we now have an `AOnionMessenger` trait, this concern is no longer
significant. Further, because we now want to use the built-in
`OnionMessenger` async event processing method, we really need a
direct referene to the `OnionMessenger` in the background
processor, which we add here optionally.

Add a parallel async event handler to `OnionMessenger`

This adds an `OnionMessenger::process_pending_events_async`
mirroring the same in `ChannelManager`. However, unlike the one in
`ChannelManager`, this processes the events in parallel by spawning
all futures and using the new `MultiFuturePoller`.

Because `OnionMessenger` just generates a stream of messages to
store/fetch, we first process all the events to store new messages,
`await` them, then process all the events to fetch stored messages,
ensuring reordering shouldn't result in lost messages (unless we
race with a peer disconnection, which could happen anyway).

Store `OnionMessenger` events in different `Vec`s

In the next commit, `OnionMessenger` events are handled in parallel
using rust async. When we do that, we'll want to handle
`OnionMessageIntercepted` events prior to
`OnionMessagePeerConnected` ones.

While we'd generally prefer to handle all events in the order they
were generated, if we want to handle them in parallel, we don't
want a `OnionMessageIntercepted` event to start being processed,
then handle an `OnionMessagePeerConnected` prior to the first
completing. This could cause us to store a freshly-intercepted
message for a peer in a DB that was just wiped because the peer
is now connected.

This does run the risk of processing a `OnionMessagePeerConnected`
event prior to an `OnionMessageIntercepted` event (because a peer
connected, then disconnected, then we received a message for that
peer all before any events were handled), that is somewhat less
likely and discarding a message in a rare race is better than
leaving a message lying around undelivered.

Thus, here, we store `OnionMessenger` events in separate `Vec`s
which we can pull from in message-type-order.

Merge pull request #3057 from G8XSU/2024-05-08-claimable-persist-3049

Minimize reads to counterparty_claimable_outpoints

Merge pull request #2947 from tnull/2024-03-log-features-if-mismatch

Merge pull request #2996 from shaavan/issue2882.2

Allow responding asynchronously to OnionMessage

Merge pull request #3063 from jirijakes/upgrade-bitcoin-031

Upgrade rust-bitcoin dependency to 0.31

Merge pull request #2931 from TheBlueMatt/2024-03-log-outbound-channels

Log available liquidity on each channel when starting routefinding

Merge pull request #3084 from jkczyz/2024-05-onion-fields

Include `RecipientOnionFields` in `Event::PaymentClaimed`

Minimize reads to counterparty_claimable_outpoints

Reads related to current/previous commitment_tx should be explicit
and reads related to older commitment_txs should be minimized.

Log available liquidity on each channel when starting routefinding

One of the most common first-steps in troubleshooting routefinding
issues is we ask for the local channel state to determine what the
available HTLC bounds are. While we log first-hop channel details
when we decline to use them, this doesn't tell us if we have
missing channels, and thus here we log all first-hop channels at
the start.

We also take this opportunity to log the limits that were violated
any time we log that we're not using a channel, rather than only
when its a first-hop.

Upgrade rust-bitcoin to 0.31

Introduce new tests for `ResponseInstruction::WithReplyPath`

- The new tests check both successful and unsuccessful `reply_path`
  creation conditions.

Refactor TestCustomMessageHandler

- Introduce a new struct for keeping expectations organized.
- Add a boolean field to track whether a response is expected,
  and hence whether a `reply_path` should be included with the response.
- Update Ping and Pong roles for bidirectional communication.
- Introduce panic for when there is no responder and we were expecting
  to include a `reply_path`.
- Refactor `handle_custom_message` code.

Refactor: Rename Request & Response to Ping & Pong

1. These two variants will be modified in an upcoming commit
   to be each other's response.
2. The names are updated to better fit their new roles.

Introduce ResponseInstruction::WithReplyPath variant.

And expand handle_onion_message_response return Type

1. Introduce a new function in OnionMessenger to create blinded paths.
2. Use it in handle_onion_message_response to create a reply_path for
   the right variant and use it in onion_message.
3. Expand the return type of handle_onion_message_response to handle three cases:
1. Ok(None) in case of no response to be sent.
2. Ok(Some(SendSuccess) and Err(SendError) in case of successful and
    unsuccessful queueing up of response messages respectively.

This allows the user to get access to the Success/Failure status of the sending
of response and handle it accordingly.