Make the custom message traits cloneable as they're deep in nested structs

Make ChannelMonitor always clonable

Rather than `ChannelMonitor` only being clonable when the signer is
clonable, we require all signers to be clonable and then make all
`ChannelMonitor`s clonable.

Avoid slices without inner references in channelmanager

`crate`-only several BOLT12 methods that require unbounded generics

These are not expressible in C/most languages, and thus must be
hidden.

Mark several types no-export which should be exported eventually

Hard-code scorer parameters to `ProbabilisticScoringFeeParameters`

The scorer currently relies on an associated type for the fee
parameters. This isn't supportable at all in bindings, and for
lack of a better option we simply hard-code the parameter for all
scorers  to `ProbabilisticScoringFeeParameters`.

Add some no-exporting of more offers code

These really could be handled in the bindings, but for lack of
immediate users there's not a strong reason to, so instead we just
disable them for now.

Avoid enums containing references with lifetimes

Having struct fields with references to other structs is tough in
our bindings logic, but even worse if the fields are in an enum.
Its simplest to just take the clone penalty here.

Export `outbound_payment` structs in their respective modules

Re-exports in Rust make `use` statements a little shorter, but for
otherwise don't materially change a crate's API. Sadly, the C
bindings generator currently can't figure out re-exports, but it
also exports everything into one global namespace, so it doesn't
matter much anyway.

Use an explicit `Sign` type on the `ChannelMonitor` read tuple

The bindings currently get confused by the implicit `Sign` type, so
we temporarily remove it on the `impl` here.

Export Onion Message structs in their respective modules

Re-exports in Rust make `use` statements a little shorter, but for
otherwise don't materially change a crate's API. Sadly, the C
bindings generator currently can't figure out re-exports, but it
also exports everything into one global namespace, so it doesn't
matter much anyway.

Restrict ChannelInfo::as_directed_from visibility

Bindings can't handle references in return types, so reduce the
visibility to pub(crate).

Simplify type aliasing somewhat around times

.. as the current C bindings generator isn't capable of handling
type aliases in generics in type alias definition currently.

Make `as_directed_to` non-public

...as the bindings generation does not currently have the ability
to map a reference to a `NodeId` inside a tuple.

Merge pull request #2678 from TheBlueMatt/2023-10-0.0.118

Cut 0.0.118

Bump crate versions to lightning 0.0.118, invoice 0.26

0.0.118 release notes

Merge pull request #2679 from TheBlueMatt/2023-10-116-bindings-1

Small bindings tweaks for 0.0.118

Fix CI on rustc 1.50 and below

rustc doesn't allow `--features` with `-p`, so we simply skip the
steps that rely on it.

Use a tuple, not a struct, for `PendingOnionMessage` in bindings

Bindings aren't currently able to handle a struct with a generic
which is actually exposed - we map all structs concretely to a
single type, whereas having fluctuating types on a struct requires
mapping the inner field to a trait first.

Since this isn't super practical, we make `PendingOnionMessage` a
tuple in bindings, rather than a struct.

Merge pull request #2676 from TheBlueMatt/2023-10-various-followups

Various Followups to 2039 and 2674

Add relevant no-export tags to functions returning builders

Because we can't map move semantics in most languages, we also
can't map our current builders. Thus, we have to mark them
no-export.

Drop an unnecessary no-export on ParsedOnionMessageContents

Do not compile the `Simple*` type aliases in `c_bindings` at all

Because the bindings changes now require further changes to our
type definitions, avoiding building the `Simple*` type aliases
entirely makes the patchset there simpler.

Fix (and test) the `c_bindings` build flag

Rather than only building with the `c_bindings` flag in certain
crates, we go ahead and test all crates with the flag in CI here.

Remove some additional excess words in `ConfirmationTarget` docs

Remove a redundant sentence in `ConfirmationTarget` docs

... and correct direction which causes force-closure in another
sentence.

Drop unused `use` import.

Avoid a redundant allocation in `InvoiceError` handling in one case

... by passing an owned `String`, rather than taking an `&str` and
`to_owned()`ing it.

Use `Default::default()` for scoring params in tests

In 26c1639ab69d6780c97a118f09e42cb42304088a we switched to using
`Default::default()` to initialize `()` for scoring parameters in
tests. A number of `()`s slipped back in recently, which we replace
here.

Merge pull request #2667 from wpaulino/random-htlc-holder-sigs-non-anchors

Use sign_holder_htlc_transaction to sign non-anchors holder HTLCs

Merge pull request #2674 from wpaulino/consider-anchor-outputs-value-balances

Consider anchor outputs value throughout balance checks and computations

Move HTLCDescriptor to sign module

Now that `HTLCDescriptor` is no longer specific to anchors, it doesn't
make sense for it to live in the `bump_transaction` module anymore.

Don't sign holder HTLCs along with holder commitments

`sign_holder_commitment_and_htlcs` never really made sense. Unlike
`sign_counterparty_commitment`, the signatures for holder HTLC
transactions may be required much later than the commitment
transaction's. While it was nice for us to only reach the signer once to
obtain all holder signatures, it's not really ideal anymore as we want
our signatures to be random and not reused.

We no longer return all holder HTLC signatures and instead defer to
obtaining them via `EcdsaChannelSigner::sign_holder_htlc_transaction`.

Remove caching of holder HTLC signatures

Since we want our holder HTLC signatures to be randomly generated and
not reused, our existing caches are useless now, so we opt to remove
them.

Use sign_holder_htlc_transaction to sign non-anchors holder HTLCs

We want to ensure we use fresh random signatures to prevent certain
classes of transaction replacement attacks at the bitcoin P2P layer.
This was already covered for commitment transactions and zero fee holder
HTLC transactions, but was missing for holder HTLC transactions on
non-anchors channels.

We can easily do this by reusing the existing
`EcdsaChannelSigner::sign_holder_htlc_transaction` method and
circumventing the existing `holder_htlc_sigs/prev_holder_htlc_sigs`
caches, which will be removed in a later commit anyway.

Apply a default max fee rather than none when paying for BOLT12

If the user declines to specify a `max_total_routing_fee_msat` in
the new BOLT12 payment methods, rather than defaulting to no limit
on the fee we pay at all, we should default to our "usual default",
ie the one calculated in
`RouteParameters::from_payment_params_and_value`.

We do this here, as well as documenting the behavior on the payment
methods.

Only account for fee spike buffer multiple on non-anchor channels

Anchor outputs channels are no longer susceptible to fee spikes as they
now mostly target the dynamic minimum mempool fee and can contribute the
remainder of fees when closing.

Consider anchor outputs value on channel open

We should make sure the funding amount of a channel can cover all its
associated costs, including the value of anchor outputs, to make sure
that it is actually usable once "opened".

Consider anchor outputs value on inbound HTLCs

This could lead us to accept HTLCs that would put the sender below
their reserve, which must never happen.

Consider anchor outputs value in get_available_balances

This could lead us to sending/forwarding HTLCs that would put us below
our reserve, forcing our counterparty to close the channel on us due to
an invalid update.

Run chanmon_consistency_test with anchor outputs channels

Provide missing derivation parameters to OnchainTxHandler

`OnchainTxHandler` will need to construct `HTLCDescriptor`s for holder
HTLCs, but it did not have access to all of the derivation parameters
that need to be provided.

Support signing non-anchors HTLCs with HTLCDescriptor

We plan to use `EcdsaChannelSigner::sign_holder_htlc_transaction` to
also sign holder HTLC transactions on non-anchor outputs channels.
`HTLCDescriptor` was only used in an anchor outputs context, so a few
things needed changing, mostly to handle the different scripts and
feerate.

Merge pull request #2660 from benthecarman/flexible-fee-rate

More flexible fee rate estimates

More flexible fee rate estimates

Merge pull request #2039 from jkczyz/2023-02-offer-flow

BOLT 12 Offers message flow

Merge pull request #2670 from yanganto/socket-addr-to-string

Impl `Display` for SocketAddress

Fix PaymentConstraints::max_cltv_expiry docs

Fix build warnings

Expand request_refund_payment docs for limitations

Onion message routing to immediate peers.

DefaultMessageRouter always fails. Update it so that it can route to a
directly connected peer. This is needed for an Offers minimum viable
product.

Add privacy section to pay_for_offer docs

Organize create_refund and pay_for_offer docs

Document InvoiceRequestFailed in ChannelManager

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

impl Display for SocketAddress

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.