Revert "Config-guard Event::InvoiceRequestFailed"

This reverts commit c7219e46831751c52026932294c33fce24121d84.

Use ChannelManager as OffersMessageHandler

OffersMessageHandler impl for ChannelManager

Define the BOLT 12 message flow in ChannelManager's
OffersMessageHandler implementation.
- An invoice_request message results in responding with an invoice
  message if it can be verified that the request is for a valid offer.
- An invoice is paid if it can be verified to have originated from a
  sent invoice_request or a refund.
- An invoice_error is sent in some failure cases.
- Initial messages enqueued for sending are released to OnionMessenger

Check offer expiry when building invoice in no-std

Building an invoice will fail if the underlying offer or refund has
already expired. The check was skipped in no-std since there is no
system clock. However, the invoice creation time can be used instead.
This prevents responding to an invoice request if the offer has already
expired.

Grammar fix in docs

BOLT12 invoice_feature methods for ChannelManager

Qualify BOLT11 ChannelManager invoice_features

Utility for creating and sending Bolt12Invoices

Add a utility to ChannelManager for creating a Bolt12Invoice for a
Refund such that the ChannelManager can recognize the PaymentHash and
reconstruct the PaymentPreimage from the PaymentSecret, the latter of
which is contained in a BlindedPath within the invoice.

Utility for paying for an Offer

Add a utility to ChannelManager for sending an InvoiceRequest for an
Offer such that derived keys are used for the payer id. This allows for
stateless verification of any Invoice messages before it is paid.

Also tracks future payments using the given PaymentId such that the
corresponding Invoice is paid only once.

Absolute expiry or timer tick payment expiration

Pending outbound payments use an absolute expiry to determine when they
are considered stale and should be fail. In `no-std`, this may result in
long timeouts as the highest seen block time is used. Instead, allow for
expiration based on timer ticks. This will be use in an upcoming commit
for invoice request expiration.

Store OffersMessages for later sending

Upcoming commits will add utilities for sending an InvoiceRequest for an
Offer and an Invoice for a Refund. These messages need to be enqueued so
that they can be released in ChannelManager's implementation of
OffersMessageHandler to OnionMessenger for sending.

These messages do not need to be serialized as they must be resent upon
restart.

Expand docs on failing expired outbound payments

Merge pull request #2636 from slanesuke/impl-ToSocketAddrs-for-Hostname

Impl ToSocketAddrs for SocketAddress

Merge pull request #2666 from tnull/2023-10-observable-update

Merge pull request #2661 from TheBlueMatt/2023-10-dup-claim-chan-hang

Immediately unblock channels on duplicate claims

Immediately unblock channels on duplicate claims

When `MonitorUpdateCompletionAction`s were added, we didn't
consider the case of a duplicate claim during normal HTLC
processing (as the handling only had an `if let` rather than a
`match`, which made the branch easy to miss). This can lead to a
channel freezing indefinitely if an HTLC is claimed (without a
`commitment_signed`), the peer disconnects, and then the HTLC is
claimed again, leading to a never-completing
`MonitorUpdateCompletionAction`.

The fix is simple - if we get back an
`UpdateFulfillCommitFetch::DuplicateClaim` when claiming from the
inbound edge, immediately unlock the outbound edge channel with a
new `MonitorUpdateCompletionAction::FreeOtherChannelImmediately`.

Here we implement this fix by actually generating the new variant
when a claim is duplicative.

Add an immediately-freeing `MonitorUpdateCompletionAction`.

When `MonitorUpdateCompletionAction`s were added, we didn't
consider the case of a duplicate claim during normal HTLC
processing (as the handling only had an `if let` rather than a
`match`, which made the branch easy to miss). This can lead to a
channel freezing indefinitely if an HTLC is claimed (without a
`commitment_signed`), the peer disconnects, and then the HTLC is
claimed again, leading to a never-completing
`MonitorUpdateCompletionAction`.

The fix is simple - if we get back an
`UpdateFulfillCommitFetch::DuplicateClaim` when claiming from the
inbound edge, immediately unlock the outbound edge channel with a
new `MonitorUpdateCompletionAction::FreeOtherChannelImmediately`.

Here we add the new variant, which we start generating in the next
commit.

Indicate to `claim_funds_internal` that we're replaying on startup

While we'd previously avoided this, this is sadly now required in
the next commit.

Log when we prepare to block a channel's next `revoke_and_ack`

This may help in debugging blocking actions in the future.

Don't apply PathFailure::ChannelUpdateMessage

If we receive a channel update from an intermediary via a failure onion
we shouldn't apply them in a persisted and network-observable way to our
network graph, as this might introduce a privacy leak. Here, we
therefore avoid applying such updates to our network graph.

Allow to verify channel updates without applying them

We introduce a new `NetworkGraph::verify_channel_update` method that
allows to check whether an update would be applied by `update_channel`.

Merge pull request #2578 from jkczyz/2023-09-offer-utilities

BOLT 12 Offers utilities

Impl ToSocketAddrs for SocketAddress

Clean up peel_onion name, parameters, and docs

For consistency with other functions and doc cleanliness.

Include a one-hop blinded path in Offer and Refund

While this doesn't add much privacy over not including any blinded
paths, it allows us to exercise code for receiving on blinded paths.

Stateless offer and refund builder utilities

Add utility functions to ChannelManager for creating OfferBuilder,
and RefundBuilder such that derived keys are used for the signing
pubkey and payer id, respectively. This allows for stateless
verification of any InvoiceRequest and Invoice messages.

Later, blinded paths can be included in the returned builders.

Also tracks future payments using the given PaymentId such that the
corresponding Invoice is paid only once.

Await for invoices using an absolute expiry

PendingOutboundPayment::AwaitingInvoice counts the number of timer ticks
that have passed awaiting a Bolt12Invoice for an InvoiceRequest. When a
constant INVOICE_REQUEST_TIMEOUT_TICKS has passed, the payment is
forgotten. However, this mechanism is insufficient for the Refund
scenario, where the Refund's expiration should be used instead.

Change AwaitingInvoice to store an absolute expiry instead. When
removing stale payments, pass the `SystemTime` in `std` and the highest
block time minus two hours in `no-std`.

Remove outdated docs

Allow sending onion messages to 1-hop blinded path

This allows for specifying the introduction node as the message
recipient.

Enqueue onion messages in handlers

When constructing onion messages to send initially (opposed to replying
to one from a handler), the user must construct an OnionMessagePath first
before calling OnionMessener::send_onion_message. Additionally, having a
reference to OnionMessener isn't always desirable. For instance, in an
upcoming commit, ChannelManager will implement OffersMessageHandler,
which OnionMessenger needs a reference to. If ChannelManager had a
reference to OnionMessenger, too, there would be a dependency cycle.

Instead, modify OffersMessageHandler and CustomOnionMessageHandler's
interfaces to include a method for releasing pending onion messages.
That way, ChannelManager may, for instance, construct and enqueue an
InvoiceRequest for sending without needing a reference to
OnionMessenger.

Additionally, OnionMessenger has responsibility for path finding just as
it does when replying to messages from a handler. It performs this when
extracting messages from the handlers before returning the next message
to send to a peer.

Generalize CustomOnionMessageContents trait

Rename CustomOnionMessageContents to OnionMessageContents and use it as
a trait bound on messages passed to OnionMessenger methods. This allows
using the trait in an upcoming commit as a bound on the contents of
PendingOnionMessage.

Also, make ParsedOnionMessageContent implement OnionMessageContents so
that Payload can be bounded by OnionMessageContents directly, but used
when either reading a ParsedOnionMessageContent or writing a specific
type of OnionMessageContents (e.g., OffersMessage).

Rename OnionMessageContents

In preparation for needing the name OnionMessageContents for a trait to
bound methods, rename it to ParsedOnionMessageContents. In the next
commit, it's use will be limited to reading only, and the new trait will
be a bound on method parameters instead.

Generalize respond_with_onion_message

OnionMessenger can send onion message responses from its handlers using
respond_with_onion_message, which finds a path to the destination and
enqueues the response for sending. Generalize this as it can be used not
only for responses but for initial sends as well.

Import msgs::OnionMessage

Clean up onion messenger parameters and docs

Avoid overloading introduction_node_id

Remove OnionMessageProvider

OnionMessageProvider is a super-trait of OnionMessageHandler, but they
don't need to be used separately. Additionally, the former is misplaced
in the events module. Remove OnionMessageProvider and add it's only
method, next_onion_message_for_peer, into OnionMessageHandler.

Update OnionMessenger docs for Offers

Merge pull request #2663 from TheBlueMatt/2023-10-peer-race-send-discon

Fix race between outbound messages and peer disconnection

Merge pull request #2658 from wpaulino/bogus-channel-reestablish

Send bogus ChannelReestablish for unknown channels

Merge pull request #2599 from Evanfeenstra/peel-onion

public static peel_onion method on OnionMessenger

Fix race between outbound messages and peer disconnection

Previously, outbound messages held in `process_events` could race
with peer disconnection, allowing a message intended for a peer
before disconnection to be sent to the same peer after
disconnection.

The fix is simple - hold the peers read lock while we fetch
pending messages from peers (as we disconnect with the write lock).

Release short_to_chan_info lock throughout forwarding_channel_not_found

Not doing so caused a lock order inversion between the locks
`ChannelManager::best_block` and `ChannelManager::short_to_chan_info`
after the addition of `test_trigger_lnd_force_close`.

It turns out that we were holding the `short_to_chan_info` for longer
than needed when processing HTLC forwards. We only need to acquire it to
quickly obtain channel info, and there aren't any other locks within
`forwarding_channel_not_found` that depend on it being held.

Disconnect peer when force closing a funded channel with an error

We do this to ensure that the counterparty will always broadcast their
latest state when we broadcast ours. Usually, they'll do this with the
`error` message alone, but if they don't receive it or ignore it, then
we'll force them to broadcast by sending them a bogus
`channel_reestablish` upon reconnecting. Note that this doesn't apply to
unfunded channels as there is no commitment transaction to broadcast.

Send bogus ChannelReestablish for unknown channels

Unfortunately, lnd doesn't force close on errors
(https://github.com/lightningnetwork/lnd/blob/abb1e3463f3a83bbb843d5c399869dbe930ad94f/htlcswitch/link.go#L2119).
One of the few ways to get an lnd counterparty to force close is by
replicating what they do when restoring static channel backups (SCBs).
They send an invalid `ChannelReestablish` with `0` commitment numbers
and an invalid `your_last_per_commitment_secret`.

Since we received a `ChannelReestablish` for a channel that doesn't
exist, we can assume it's likely the channel closed from our point of
view, but it remains open on the counterparty's side. By sending this
bogus `ChannelReestablish` message now as a response to theirs, we
trigger them to force close broadcasting their latest state. If the
closing transaction from our point of view remains unconfirmed, it'll
enter a race with the counterparty's to-be-broadcast latest commitment
transaction.

public static peel_onion method on OnionMessenger

Merge pull request #2662 from jkczyz/2023-10-chain-hash

Use `ChainHash` instead of `BlockHash` as applicable

Merge pull request #2665 from TheBlueMatt/2023-10-scanable-test-logs

Make test log lines somewhat more eye-scannable

Use ChainHash instead of BlockHash as applicable

ChainHash is more appropriate for places where an arbitrary BlockHash is
not desirable. This type was introduced in later versions of the bitcoin
crate, thus BlockHash was used instead.

Using ChainHash also makes it easier to check if ChannelManager is
compatible with an Offer.

Merge pull request #2664 from TheBlueMatt/2023-10-ci-disk-usage

Reduce disk usage in CI

Merge pull request #2625 from tnull/2023-09-moar-tests-n-fixes

Improve test coverage of #2575 router fixes

Make test log lines somewhat more eye-scannable

When running tests, our log output should be reasonably readable
by developers, but currently it repeats the module twice (via the
module and file name), and then starts the log line at a variable
location.

Instead, we only print the module and then align the start of the
log lines so that the output is much more scannable.

Reduce disk usage in CI

Recently github appears to have reduced the available free disk
space in actions runs, causing CI to fail with out of space errors.
Here we simply run `cargo clean` a few times in CI to reduce our
disk usage somewhat.

Merge pull request #2655 from TheBlueMatt/2023-10-no-test-net

Replace `lightning-block-sync` test that depended on `foo.com`

Merge pull request #2639 from vladimirfomene/fix-final-incorrect-cltv

Fix final incorrect cltv

fix: use the update_add_htlc's cltv_expiry for comparison

As noted in BOLT 4, we should be using the update_add_htlc's cltv_expiry,
not the CLTV expiry set by the sender in the onion for this comparison.
See here: https://github.com/lightning/bolts/blob/4dcc377209509b13cf89a4b91fde7d478f5b46d8/04-onion-routing.md?plain=1#L334

Replace `lightning-block-sync` test that depended on `foo.com`

Our tests should generally not rely on internet access, and should
not rely on the behavior of any given remote server. However, one
of the `endpoint_tests` in `lightning-block-sync::http` relied on
`foo.com` resolving to a single socket address, which both might
change in the future and makes our tests fail without internet.

Merge pull request #2650 from TheBlueMatt/2023-10-make-clippy-shut-up

Make clippy shut up about `PartialOrd` and `Ord` both impl'd

Merge pull request #2657 from Fedeparma74/fix-close-channel-deadlock

Fix deadlock when closing an unavailable channel

Fix deadlock when closing an unavailable channel

Merge pull request #2652 from tnull/2023-10-deref-achannelmanager

Merge pull request #2651 from G8XSU/rm-same-feerate-log

Remove log for not changing feerate when it was equal

Merge pull request #2649 from benthecarman/display-outpoint

Impl Display for Outpoint

Have methods take `AChannelManager` as `Deref::Target`

Impl Display for Outpoint

Remove log for not changing feerate when it was equal

Log is not required in this case and creates unnecessary log lines at
trace level.

Make clippy shut up about `PartialOrd` and `Ord` both impl'd

Clippy gets mad that we have an implementation of `ParialOrd` and
`Ord` separately, even though both are identical. Making
`ParitalOrd` call `Ord` makes clippy shut up.

Merge pull request #2640 from sr-gi/20231003-expose-from-be-bytes

Makes Features::from_be_bytes public

Makes Features::from_be_bytes public

Downstream projects building Feature<T> are most likely doing so with a
big-endian byte array, however only `from_le_bytes` is exposed.

Merge pull request #2645 from TheBlueMatt/2023-10-changelog-dates

Set the timestamp for and provide diff stats for 0.0.117 CHANGELOG

Set the timestamp for and provide diff stats for 0.0.117 CHANGELOG

Merge pull request #2620 from TheBlueMatt/2023-09-cut-0.0.117

Cut 0.0.117

Bump crate versions to 0.0.117/invoice 0.25

Add 0.0.117 release notes

Merge pull request #2631 from TheBlueMatt/2023-09-pm-no-refs-reqd

Fix `Simple*PeerManager` to not require refs to the `UtxoLookup`

Merge pull request #2634 from TheBlueMatt/2023-09-claimable-unwrap

Avoid unwrap'ing `channel_parameters` in to_counterparty signing

Clean up at least some lifetimes on `SimpleRefPeerManager`

Rather than simply a, b, c, d...we at least use names for a few
things, also splitting the reused 'f lifetime.

Note when we're allowed to unwrap channel parameters in docs

This further documents the parameter-fetching utilities in
`InMemorySigner` to hopefully make them more robust against future
spurious `unwrap`s.

Make `InMemorySigner` parameter-fetching utilities return `Option`s

In the previous commit we fixed a bug where we were spuriously
(indirectly) `unwrap`ing the `channel_parameters` in
`InMemorySigner`. Here we make such bugs much less likely in the
future by having the utilities which do the `unwrap`ing internally
return `Option`s instead.

This makes the `unwrap`s clear at the callsite.

Merge pull request #2595 from TheBlueMatt/2023-09-117-bindings-part1

Various cleanups to make bindings generation simpler

Merge pull request #2632 from TheBlueMatt/2023-09-writeable-rwlock

Implement Readable/Writeable for RwLock wrappers

Merge pull request #2633 from TheBlueMatt/2023-09-expose-onion-parse

Expose `parse_onion_address` publicly in `no-std`

Avoid unwrap'ing `channel_parameters` in to_counterparty signing

Previously, `StaticPaymentOutputDescriptor`s did not include
`channel_parameters` for the signer. As a result, when going to
spend old `StaticPaymentOutputDescriptor`s,
`InMemorySigner::sign_counterparty_payment_input` may be called
with `channel_parameters` set to `None`. This should be fine, but
in fa2a2efef47b5da48ac7a239f3d8a835a7f28164 we started relying on
it (indirectly via `channel_features`) for signing. This caused an
`unwrap` when spending old output descriptors.

This is fixed here by simply avoiding the unwrap and assuming old
`StaticPaymentOutputDescriptor`s represent non-anchor channels.

Remove unused `mem::drop` which drops a reference

Fix new unused variable warning in `test_utils.rs`

Use `crate::prelude::*` to load `Vec`, rather than `crate::Vec`

This is kinda dumb, but the bindings get confused when referring
to `Vec` absolutely in a `use` statement, and there's no reason not
to load our prelude everywhere.

Drop various bounds on types passed to `MonitorUpdatingPersister`

The new `MonitorUpdatingPersister` has a few redundant type bounds
(re-specified on functions after having been specified on the
struct itself), which we remove here.

Further, it requires a `Deref<FeeEstimator>` which is `Clone`able.
This is generally fine in rust, but annoying in bindings, so we
simply elide it in favor if a `&Deref<FeeEstimator>`.

Make `create_onion_message` a freestanding function

The new `create_onion_message` function in `OnionMessenger` is hard
to handle - it has various generic requirements indirectly via the
struct, but they're not bounded by any of the method parameters.
Thus, you can't simply call `OnionMessenger::create_onion_message`,
as various bounds are not specified.

Instead, we move it to a freestanding function so that it can be
called directly without explicitly setting bounds.

Mark `AChannelManager` no-export

The trait itself has no purpose for bindings, as all structs are
concretized anyway. Further, the bindings have specific handling
for generic bounding traits like this.

Mark `SpendableOutputDescriptor::to_psbt_input` as no-export

Its honestly likely not all that useful as its not materially
interoperable with other PSBT libraries. Instead, users should
simply fetch the full PSBT and use the inputs from it as they see
fit.

Drop unnecessary crate:: prefix when accessing `bitcoin` in macro

Unexported macros don't need to use the `$crate` prefix.

Avoid ref to a `Vec` when accessing custom onion TLVs

The bindings can't easily return a reference to a `Vec`, so we
instead split the implementation into vec/slice depending on the
`c_bindings` flag.

Avoid blanket impls in bindings builds

The C bindings implements `Deref` for all traits, so having a
blanket `Deref` implementation ends up conflicting with this.

Simplify score bounding with a unified type

In a few places we require a unified scorer, which implements both
`ScoreLookUp` and `ScoreUpdate`. Rather than double-bounding (which
the bindings generator can't handle directly), we use a top-level
`Score` trait which requires both and is implemented for all
implementers of both supertraits.

Remove unnecessary bounds in scoring

In our scoring logic we have a handful of unnecessary bounds,
leading to extra diff in the bindings branch when those bounds have
to be removed as well as a few cases where bindings generation
simply gets confused.

Here we remove a number of bounds across the scoring traits and
impls, cleaning things up and simplifying bindings changes.

Use `Default::default()` to construct `()` as score-updating param

In 6b0d94a3029f74de3a7542cbba0d48c2f7e5866b we switched most tests
to `Default::default()` for scoring parameters passed to
route-fetching. Here we do the same for the scoring parameters when
passed to score-updating.

Expose `parse_onion_address` publicly in `no-std`

The reason for having a separate `parse_onion_address` from
`FromStr` is to have an onion parsing function in `no-std`, but
when we added it we forgot to make it public. We do this here, as
well as fix a few compilation warnings in `no-std`.

Switch `Simple*ChannelManager` locks around `Score` to `RwLock`

This switches the locks used around `ProbabilisticScorer` in
`Simple*ChannelManager` type aliases to `RwLock`.

Fix `Simple*PeerManager` to not require refs to the `UtxoLookup`

`UtxoLookup` doesn't strictly need to be referenced from the
`PeerManager`, and in fact the new `GossipVerifier` in
`lightning-block-sync` requires itself to be owned by the
`PeerManager` (for circular type reasons).

This allows us to use `lightning-block-sync`'s `GossipVerifier`
with `SimpleArcPeerManager` in ldk-sample.

Implement `Readable`/`Writeable` for `RwLock` wrappers

We now support separate R/W locks in `LockableScore`, which allow
us to do routefinding in parallel, however in order to support
`WriteableScore` for such users we need to implement `Writeable`
for `RwLock` wrappers around `Writeable` types, which we do here.