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.

Merge pull request #3011 from jkczyz/2024-04-compact-blinded-path-creation

Compact blinded path creation

Add missing copyright statement

Compact introduction node test vector

Compact a BlindedPath's introduction node

Add a method to BlindedPath that given a network graph will compact the
IntroductionNode as the DirectedShortChannelId variant. Call this method
from DefaultMessageRouter so that Offer paths use the compact
representation (along with reply paths). This leaves payment paths in
Bolt12Invoice using the NodeId variant, as the compact representation
isn't as useful there.

Unwrap reply_path in extract_invoice_request

Pass ForwardNode when creating BlindedPath

Instead of passing Vec<PublicKey> to MessageRouter::crate_blinded_path,
pass Vec<ForwardNode>. This way callers can include a short_channel_id
for a more compact BlindedPath encoding.

Support NextHop::ShortChannelId in BlindedPath

When sending an onion message to a blinded path, the short channel id
between hops isn't need in each hop's encrypted_payload since it is not
a payment. However, using the short channel id instead of the node id
gives a more compact representation. Update BlindedPath::new_for_message
to allow for this.

Merge pull request #3006 from arik-so/arik/trampoline/2024-04-trampoline-onion-deserialization

Trampoline Onion Deserialization

Merge pull request #3051 from TheBlueMatt/2024-04-2982-123-fix

Don't attempt to resume channels if we already exchanged funding

Don't attempt to resume channels if we already exchanged funding

ddf75afd16 introduced the ability to re-exchange our `ChannelOpen`
after a peer disconnects if we didn't complete funding on our end.
It did not implement nor consider what would happen if we
re-connected after we created our own funding transactions, and
currently it panics (and even if it did not it would replay the
`FundingTransactionGenerated` event to users).

While we'd very much like to replay the `open_channel` flow even
if we have already received an `accept_channel` and funded the
channel, we cannot as the peer will likely provide different key
material in their `accept_channel`, causing us to need a different
funding transaction.

Thus, here, we simply close channels which have been funded but not
yet signed when our peer disconnects.

Merge pull request #3079 from jkczyz/2024-05-expects-quantity

Add missing `Offer::expects_quantity` to tests

Add missing Offer::expects_quantity to tests

Merge pull request #3038 from TheBlueMatt/2024-05-no-dir-with-on-side-offline

Ignore partially-pruned channels during routing

Merge pull request #3026 from valentinewallace/2024-04-limit-path-len

Limit payment path length based on `payment_metadata`, custom TLVs, etc.

Merge pull request #3073 from tnull/2024-05-bump-nits

Fix minor nits in `BumpTransactionEventHandler`

Merge pull request #3068 from toxeus/main

Re-export bitcoin crate

Test Trampoline onion (de)serialization round trip.

Make Trampoline onion deserializable.

Add public util on RouteParameters for setting max path length.

Test routing payment parameters' max path length setting and usage.

outbound_payment: set max path length in PaymentParameters.

So the router knows how long the maximum payment path can be.

Test utils: include payment_metadata in PassAlongPathArgs.

Abide by max path length param in router.

Also adds some testing by augmenting existing tests.

Add max path length knob to PaymentParameters.

Will be used so the outbound_payment module can calculate the maximum path
length with knowledge of any custom TLVs or payment metadata present.

Merge pull request #3069 from TheBlueMatt/2024-06-log-chan-count

Log how many nodes/channels we have synced when we try to route

Log how many nodes/channels we have synced when we try to route

A common issue in LN is not having fully synced the network graph
when we attempt to send a payment. This should be improved
substantially with gossip v1.5, but for now we should improve our
debugability by logging how many nodes we have in our graph when
we attempt to find a route.

Re-export bitcoin crate

For the same reason the `bitcoin` crate is re-exporting
the `secp256k1` crate the `lightning` crate should
re-export the `bitcoin` crate: to ease the burden on
calling code to maintain compatible `bitcoin` versions.

The `lightning` crate makes heavy use of types defined in
(or re-exported by) the `bitcoin` crate. Compilation will
fail if e.g. comparisons or `match` expressions are done with
types from `bitcoin` crate versions with a non-equal minor
version. This forces calling code to depend on a `bitcoin`
crate with a compatible version. This becomes a maintenance
nightmare once two or more crates, that use `bitcoin` types
in their public API, are used in calling code simultaneously.

Fix minor nits in `BumpTransactionEventHandler`

Extract onion_utils::build_onion_payloads_callback helper.

Will be useful when we want to calculate the total size of the payloads without
actually allocating for them.

Merge pull request #3036 from TheBlueMatt/2024-05-filter-color

Provide more color in filter registration methods

Make MAX_PATH_LENGTH_ESTIMATE const pub and expand doc comment.

Will be used in the next commit when we make this configurable in
PaymentParameters.

TestRouter: support checking only that route params are as expected.

Remove unnecessary RecipientOnionFields clone.

Doable now that we take Vecs by reference in OutboundOnionPayload.

OutboundOnionPayload: hold Vec fields as references.

Will be useful when we reuse this enum to calculate the maximum path length,
to avoid cloning the vecs.

Merge pull request #3061 from TheBlueMatt/2024-05-bindings-upstream

Minor bindings tweaks

Allow any `Deref` to an `EntropySource` in `BlindedPath` building

This matches our normal API semantics and allows, for example,
`Arc`s to `EntropySource`s.

impl `Clone` on various public (mostly BOLT12) types

This is required for bindings as passing types from Rust to GC'd
languages can't map the concept of a type that has a lifetime of
the called function but instead needs to clone for safety.

Expose `ChannelManager` offer constructors in bindings

Mark `io_extras` as no-bindings-export as its not for public use

Make `offers::Amount` `Copy` and export it in bindings

`Amount` is less than two pointers long, so there's no reason it
shouldn't be `Copy`. Further, because its an enum, bindings can't
map a reference to it in an `Option`. Thus, here, we simply make it
`Copy` and return it in `Option`s rather than a reference to it.

Use prelude by universal import, rather than single import

This avoids the bindings trying to figure out what a
`lightning::prelude::Vec` is rather than matching it as a `Vec`.

Export `ChannelId` in bindings rather than `[u8; 32]`

Now that `ChannelId` has useful constructors and methods we need
to start exposing it to bindings users rather than relying on using
`[u8; 32]`.

Skip `BestBlock::new` in bindings as we already have one

Merge pull request #3058 from benthecarman/deref-empty-nod-id-lookup

impl Deref for EmptyNodeIdLookUp

Merge pull request #3059 from jkczyz/2024-05-drop-writeable-signer

Remove `WriteableEcdsaChannelSigner` trait

Remove WriteableEcdsaChannelSigner trait

WriteableEcdsaChannelSigner is no longer needed now that
EcdsaChannelSigner isn't written in OnchainTxHandler.

Stop writing EcdsaChannelSigner

EcdsaChannelSigner is no longer deserialized as of version 0.0.113 and
downgrades before version 0.0.113 are no longer supported as of version
0.0.119.

Merge pull request #2930 from jbesraa/Add-PaymentHash-to-Record

Add `PaymentHash` to `Record`

Merge pull request #2973 from valentinewallace/2024-03-om-mailbox

Support intercepting onion messages for offline peers

impl Deref for EmptyNodeIdLookUp

Fill in top-level docs for onion message offline peer interception.

Limit OnionMessenger event buffer size.

Manually implement Debug for onion message packets.

Previously we derived Debug, but that caused a lot of unreadable encrypted
bytes to be printed.

Test offline peer onion message interception.

Fix outdated comment in onion message functional test.

Refactor MessengerNode test util construction to take config.

Will be used in the next commit when another config parameter is added.

Support forwarding prebuilt onion messages in OnionMessenger.

OnionMessenger: support generating peer connection events.

Useful if we are in the mode of interception OMs for offline peers, so
users know when to re-inject intercepted OMs.

Support generating events when an OM for an offline peer is received.

Docs will be added in upcoming commits.

Merge pull request #3041 from G8XSU/followup-2957

Followups to #2957

Ignore partially-pruned channels during routing

If we prune one side of a channel's `ChannelUpdateInfo` that means
the node hasn't been online for two weeks (as they haven't
generated a new `channel_update` in that time). In such cases, even
if we haven't yet pruned the channel entirely, we should definitely
not be treating these channels as candidates for routing.

Note that this requires some additional `channel_update`s in the
router tests, but all of the new ones are added as disabled
channels.

Fixes #1824

Add `payment_hash` to `WithChannelMonitor`

Add `PaymentHash` to `Record`

    Adding the `payment_hash` to `Record` so we are able to track it
    in logs.

Merge pull request #2907 from shaavan/issue2882

Introduce ResponseInstructions for OnionMessage Handling

Merge pull request #3012 from TheBlueMatt/2024-04-0.0.123-rl

Add draft release notes for 0.0.123

Merge pull request #3054 from TheBlueMatt/2024-04-fuzz-bolt11

Add fuzzing coverage for BOLT11 invoice deserialization

Bump `possiblyrandom` to 0.2

I'd uploaded `possiblyrandom` 0.1 to reserve the crate name but
with a dummy library so now we need ot use 0.2 for the release.

Add changelog entries for 0.0.123

Use consistent byte/char offsets when parsing invoice HRPs

When parsing lightning-invoice HRPs we want to read them
char-by-char, tracking at which offset different fields were. Prior
to this commit this was done first by reading char-by-char and then
by indexing using the byte offset which works for ASCII strings but
fails on multi-byte characters.

This commit fixes this issue by simply always walking byte-by-byte
and rejecting multi-byte characters which don't belong in HRPs.

Substantially increase coverage in BOLT11 deserialization fuzzer

Move existing BOLT11 fuzz test to the `fuzz` crate

Merge pull request #3046 from TheBlueMatt/2024-03-fees-are-dust

Fix the `full_stack_target` breakage test and doc feerate requests

Implement ResponseInstruction Usage in OnionMessage Handling

This commit integrates the newly introduced ResponseInstruction structs
and enums into the codebase for handling OnionMessage responses.

Fix the `full_stack_target` breakage test and doc feerate requests

When we added the additional deust exposure checks in
702196819e6445048b803574fcacef77d5ce8c9c we added several
additional feerate fetches which broke the `full_stack_target`
change-detection test.

This updates the hard-coded test to support the new feerate fetches
and also includes a comment on `FeeEstimator` to indicate that
users really need to be caching feerates as otherwise they'll slow
us down.

Merge pull request #3045 from TheBlueMatt/2024-03-fees-are-dust

Include excess counterparty commitment transaction fees in dust exposure

Add a simple test of the new excess-fees-are-dust behavior

Update default dust exposure limit and the documentation thereof

Now that we're including excess counterparty commitment transaction
fees in our dust calculation, we need to update the docs
accordingly. We do so here, describing some of the considerations
and risks that come with the new changes.

We also take this opportunity to double the default value, as users
have regularly complained that non-anchor channels fail to send
HTLCs with the default settings with some feerates.

Fixes #2922

Include excess commitment transaction fees in dust exposure

Transaction fees on counterparty commitment transactions are
ultimately not our money and thus are really "dust" from our PoV -
they're funds that may be ours during off-chain updates but are not
ours once we go on-chain.

Thus, here, we count any such fees in excess of our own fee
estimates towards dust exposure. We don't bother to make an
inbound/outbound channel distinction here as in most cases users
will use `MaxDustExposure::FeeRateMultiplier` which will scale
with the fee we set on outbound channels anyway.

Note that this also enables the dust exposure checks on anchor
channels during feerate updates. We'd previously elided these as
increases in the channel feerates do not change the HTLC dust
exposure, but now do for the fee dust exposure.

Stop tracking chain_sync_monitor_persistences in TestPersister

Make ChannelMonitor chain-sync log a trace log

Minor Doc fixes after #2957

Merge pull request #3039 from valentinewallace/2024-04-invoice-amt-msats-overflow

Fix overflow in invoice amount setter.

Merge pull request #2957 from G8XSU/pause-events

Don't pause events for chainsync persistence

Fix overflow in invoice amount setter.

Provide more color in filter registration methods

A few years ago we had repeated user confusion dealing with the
`Filter` methods and exactly how they differ. Here we try to add a
bit more color in several ways as suggested by users in a few
places - listing examples of why the methods are used as well as
ensuring its clearly communicated that not all parameters need be
used.

Fixes #1069

Merge pull request #3035 from TheBlueMatt/2024-04-upstream-123-bindings

Keep newlines between releases in CHANGELOG consistent

Add release note for 0.0.122 with just three PRs.

Merge pull request #3018 from jkczyz/2024-04-optional-description

Optional description for `Offer` and `Refund`

Merge pull request #3029 from TheBlueMatt/2024-04-fix-batch-funding-failures

Add error handling for channels which fail to be created in `funding_transaction_generated_intern`

Introduce ResponseInstructions for OnionMessage Handling

- Currently, handle_message (or handle_custom_message) only exposes
  the generated response for an OnionMessage, lacking the necessary
  reply_path for asynchronous responses.

- This commit introduces a new flow for OnionMessage handling.

- Instead of solely taking the message as input, handle_message now accepts
  an Optional `responder`, returning a `ResponseInstruction` containing both
  the response and the reply_path.

- `ResponseInstruction` utilizes different enum variants to indicate how
  `handle_onion_message_response` should handle the response.

- This enhancement enables exposing the reply_path alongside the response
  and allows for more complex response mechanisms, such as responding with
  an added reply_path.

- The commit introduces the foundational framework (structs & enums) for this new flow.

Only require description when offer has an amount

The spec was changed to allow excluding an offer description if the
offer doesn't have an amount. However, it is still required when the
amount is set.

Swap `UserConfig::default()` for `test_default_channel_config`

As LDK changes, `UserConfig::default()` may imply marginally
different behavior, whereas `test_default_channel_config` is
intended to tweak defaults to provide a stable behavior for test
contexts.

This commit changes a few uses of `UserConfig::default()` to
`test_default_channel_config` in cases that will fail over the
coming commits due to dust changes.

Correct indentation in `get_pending_htlc_stats`

The previous commit left indentation in `get_pending_htlc_stats`
deliberately wrong, to ease reviewability. This commit fixes the
indentation.

Unify `get_{inbound,outbound}_pending_htlc_stats`

In most cases we already call both in a pair, and in fact always
consolidate some of the returned values across both accessors, so
there's not much reason to have them be separate methods.

Here we merge them.

Merge pull request #3033 from TheBlueMatt/2024-04-notify-bp-on-blocks

Wake `background-processor` from `ChainMonitor` on new blocks

Wake `background-processor` from `ChainMonitor` on new blocks

When we receive a new block we may generate
`Event::SpendableOutputs` in `ChannelMonitor`s which then need to
be processed by the background processor. While it will do so
eventually when its normal loop goes around, this may cause user
tests to be delayed in finding events, so we should notify the BP
immediately to wake it on new blocks.

We implement that here, unconditionally notifying the
`background-processor` whenever we receive a new block or confirmed
transactions.

Update documentation on `[u8; 32]` wrappers for clarity

Move `[u8; 32]` wrapper types to a common module

The `PaymentHash`, `PaymentSecret`, `PaymentPreimage`, and
`ChannelId` types are all small wrappers around `[u8; 32]` and are
used throughout the codebase but were defined in the top-level
`ln/mod.rs` file and the relatively sparsely-populated
`ln/channel_id.rs` file.

Here we move them to a common `types` module and go ahead and
update all our in-crate `use` statements to refer to the new
module for bindings. We do, however, leave a `pub use` alias for
the old paths to avoid upgrade hassle for users.