Add Option<Vec<SocketAddress>> to OnionMessagePath

MessageRouter::find_path is given a Destination to reach via a set of
peers. If a path cannot be found, it may return a partial path such that
OnionMessenger can signal a direct connection to the first node in the
path is needed. Include a list of socket addresses in the returned
OnionMessagePath to allow OnionMessenger to know how to connect to the
node.

This allows DefaultMessageRouter to use its NetworkGraph to return
socket addresses for gossiped nodes.

Add NetworkGraph reference to DefaultMessageRouter

When buffering onion messages for a node that is not connected as a
peer, it's possible that the node does not exist. Include a NetworkGraph
reference in DefaultMessageRouter so that it can be used to check if the
node actually exists. Otherwise, an malicious node may send an onion
message where the reply path's introduction node doesn't exist. This
would result in buffering messages that may never be delivered.

Buffer onion messages requiring a connection

MessageRouter::find_path returns a path to use when sending an onion
message. If the first node on the path is not connected or does not
support onion messages, sending will fail with InvalidFirstHop. Instead
of failing outright, buffer the message for later sending once the first
node is a connected peer.

Destination in OnionMessenger::send_onion_message

OnionMessenger::send_onion_message takes an OnionMessagePath. This isn't
very useful as it requires finding a path manually. Instead, have the
method take a Destination and use OnionMessenger's MessageRouter to
construct the path. Later, this will allow for buffering messages where
the first node in the path isn't a direct connection.

Use a message buffer abstraction in OnionMessenger

Onion messages are buffered for sending to the next node. Since the
network has limited adoption, connecting directly to a peer may be
necessary. Add an OnionMessageBuffer abstraction that can differentiate
between connected peers and those are pending a connection. This allows
for buffering messages before a connection is established and applying
different buffer policies for peers yet to be connected.

Merge pull request #2764 from TheBlueMatt/2023-11-chacha-cleanup

Trivial ChaCha cleanups

Merge pull request #2642 from Sharmalm/2346

 logging every sent receive onion message

Merge pull request #2753 from TheBlueMatt/2023-11-inbound-preimages

Provide inbound HTLC preimages to the `EcdsaChannelSigner`

Merge pull request #2771 from tnull/2023-12-log-details-for-ignored-first-hop

Log additional details when ignoring first hops

Provide inbound HTLC preimages to the `EcdsaChannelSigner`

The VLS signer has a desire to see preimages for resolved forwarded
HTLCs when they are first claimed by us, even if that claim was for
the inbound edge (where claiming strictly increases our balance).

Luckily, providing that information is rather trivial, which we do
here.

Fixes #2356

Merge pull request #2769 from TheBlueMatt/2023-12-2314-cleanups-3

Post-#2314 Cleanups #3

Log additional details when ignoring first hops

Users are often confused when we fail to find a route due to some
requirements on the first hop are not being met. While we now take note
and log such candidates, we still previously required users to check
additional details to figure out why exactly the router refused to route
over a particular first hop.

Here, we add additional TRACE logging, in particular for
`ChannelDetails::next_outbound_htlc_limit_msat` and
`ChannelDetails::next_outbound_htlc_minimum_msat` when they are
relevant.

Merge pull request #2768 from benthecarman/preimage-helper

Add helper function for getting preimage from PaymentPurpose

Merge pull request #2766 from TheBlueMatt/2023-12-2314-cleanups-2

Marginally optimize test logging

Doc that `Record::node_id` may be missing even with `channel_id`

There are various place where we log something related to a channel
but fail to fill in the channel's counterparty information. This is
somewhat surprising, given channel counterparty information is
always known, but simply is sometimes not readily accessible to LDK
when a log is printed.

Set log metadata in a few additional locations in `channelmanager`

Log next-hop metadata when forwarding or failing to forward HTLC

Include next-hop counterparty node id in log metadata when sending

Add missing counterparty node id metadata to logs in HTLC decoding

Add helper function for getting preimage from PaymentPurpose

Include counterparty node id and channel id in shutdown log

This avoids an important shutdown log being about a channel but not
having the channel metadata.

Add missing `unwrap` in `reload_tests.rs`

Marginally optimize test logging

973636bd2ab2ba35fb8b9703f1d5d0e72f069cdc introduced a new `HashMap`
in the `TestLogger` but then did lookups by iterating the entire
map. This fixes that, and also takes this opportunity to stop
allocating new `String`s for the module to store each log entry in
the `TestLogger`

logging every sent and receive onion message

Logs every sent + receive for P2P messages
solves #2346

Merge pull request #2314 from henghonglee/issue-2292

Add peer_id and channel_id explicitly to log records

Refactor ChainMonitor::update_channel error case

Move the handling of ChannelMonitorUpdateStatus::UnrecoverableError to
the point of error to avoid needing an unwrap later when re-wrapping the
logger.

Remove unused handle_error macro rule

Use wrapper to add context to logging

Using a decorator pattern, add peer_id and channel_id to Record
stored on Logger.

Add WithChannelMonitor

Add WithChannelContext

Add WithChannelDetails

Add WithContext and Tests

Add semantics to logger::Records

Include optional peer and channel ids to logger::Record. This will be
used by wrappers around Logger in order to provide more context (e.g.,
the peer that sent a message, the channel an operation is pertaining to,
etc.). Implementations of Logger can include this as metadata to aid in
searching logs.

Pass Record by value to Logger

Instead of passing a reference to a Record, pass the Logger an owned
Record so that it can be decorated with semantic context.

Merge pull request #2540 from valentinewallace/2023-08-blinded-errors

Route blinding: support forwarding as the intro node

Add inline suggestion tags to ChaCha20 SIMD wrappers

These are obviously super hot, and while LLVM shouldn't be
braindead here you never know, so we might as well `#[inline]`.

Drop unnecessary SIMD subtraction in ChaCha20 `round`

While its all constant arithmetic to calculate the shift, which
LLVM likely optimizes out for us, there's no reason to do it four
times, which just makes the code harder to read.

Test blinding point serialization in Channel.

Add release note for blinded HTLC backwards compat.

Test intro node failing blinded intercept HTLC.

Test intro node blinded HTLC failing in process_pending_htlc_fwds.

Correctly fail back downstream-failed blinded HTLCs as intro

Correctly fail back blinded inbound fwd HTLCs when adding to a Channel

As the intro node.

Extract blinded route param creation into test util

Correctly fail back on outbound channel check for blinded HTLC

Forwarding intro nodes should always fail with 0x8000|0x4000|24.

Test blinded forwarding payload encoded as receive error case

Test blinded forward failure to calculate outbound cltv expiry

Intro node failure only.

Remove now-unused Readable impl for ReceiveTlvs

Support forwarding blinded HTLCs as intro node.

Error handling will be completed in upcoming commits.

Parse blinded forward-as-intro onion payloads

Previously, we only parsed blinded receive payloads.

Set update_add blinding point on HTLC forward

Used by the next hop to decode their blinded onion payload.

Parameterize Channel's htlc forward method by outbound blinding point

Used in the next commit to set the update_add blinding point on HTLC forward.

Set HTLCPreviousHopData::blinded on intro node forward.

Useful so we know to fail back blinded HTLCs where we are the intro node with
the invalid_onion_blinding error per BOLT 4.

We don't set this field for blinded received HTLCs because we don't support
receiving to multi-hop blinded paths yet, and there's no point in setting it
for HTLCs received to 1-hop blinded paths because per the spec they should fail
back using an unblinded error code.

Persist whether an HTLC is blinded in HTLCPreviousHopData.

Useful so we know to fail blinded intro node HTLCs back with an
invalid_onion_blinding error per BOLT 4.

Another variant will be added to the new Blinded enum when we support
receiving/forwarding as a non-intro node.

Store whether a forwarded HTLC is blinded in PendingHTLCRouting

We need to store the inbound blinding point in PendingHTLCRouting in order to
calculate the outbound blinding point.

The new BlindedForward struct will be augmented when we add support for
forwarding as a non-intro node.

Persist outbound blinding points in Channel

A blinding point is provided in update_add_htlc messages if we are relaying or
receiving a payment within a blinded path, to decrypt the onion routing packet
and the recipient-provided encrypted payload within. Will be used in upcoming
commits.

Parse blinded onion errors in tests only.

So we can make sure they're encoded properly.

onion_utils: extract decrypting faiure packet into method

Will be used in the next commit to parse onion errors from blinded paths in
tests only.

Parse blinding point in UpdateAddHTLC

A blinding point is provided in update_add_htlc messages if we are relaying or
receiving a payment within a blinded path, to decrypt the onion routing packet
and the recipient-provided encrypted payload within. Will be used in upcoming
commits.

Merge pull request #2739 from Evanfeenstra/channelmanager-utils

move static channelmanager functions into their own file

Merge pull request #2721 from TheBlueMatt/2023-11-log-forward-peer

Handle missing case in reestablish local commitment number checks

Merge pull request #2755 from arik-so/arik/taproot-2023-11-followup-2512

Followups to 2512

Remove unused Taproot import.

Move validate_counterparty_revocation to ChannelSigner.

Remove superfluous commitment_number parameter.

Gate Taproot-related todos behind cfg flag.

move static channelmanager functions into their own file

Merge pull request #2512 from arik-so/taproot/2023-08-taproot-signer-variant

Taproot signer variant

Merge pull request #2749 from TheBlueMatt/2023-11-2744-followups

Add `channel_keys_id` to `SpendableOutputDescriptor::StaticOutput`

Move ECDSA-specific signers into ecdsa.rs

To separate out the logic in the `sign` module, which will start to be
convoluted with multiple signer types, we're splitting out each signer
type into its own submodule, following the taproot.rs example from a
previous commit.

Reparametrize ChannelSignerType by SignerProvider.

ChannelSignerType is an enum that contains variants of all currently
supported signer types. Given that those signer types are enumerated
as associated types in multiple places, it is prudent to denote one
type as the authority on signer types.

SignerProvider seemed like the best option. Thus, instead of
ChannelSignerType declaring the associated types itself, it simply
uses their definitions from SignerProvider.

Add TaprootSigner variant to SignerProvider.

Previously, SignerProvider was not laid out to support multiple signer
types. However, with the distinction between ECDSA and Taproot signers,
we now need to account for SignerProviders needing to support both.

This approach does mean that if ever we introduced another signer type
in the future, all implementers of SignerProvider would need to add it
as an associated type, and would also need to write a set of dummy
implementations for any Signer trait they do not wish to support.

For the time being, the TaprootSigner associated type is cfg-gated.

Introduce TaprootSigner trait.

For Taproot support, we need to define an alternative trait to
EcdsaChannelSigner. This trait will be implemented by all signers
that wish to support Taproot channels.

Rename SignerProvider's Signer to EcdsaSigner.

Handle missing case in reestablish local commitment number checks

If we're behind exactly one commitment (which we've revoked), we'd
previously force-close the channel, guaranteeing we'll lose funds
as the counterparty has our latest local commitment state's
revocation secret.

While this shouldn't happen because users should never lose data,
sometimes issues happen, and we should ensure we always panic.

Further, `test_data_loss_protect` is updated to test this case.

Clean up error messages and conditionals in reestablish handling

When we reestablish there are generally always 4 conditions for
both local and remote commitment transactions:
 * we're stale and have possibly lost data
 * we're ahead and the peer has lost data
 * we're caught up
 * we're nearly caught up and need to retransmit one update.

In especially the local commitment case we had a mess of different
comparisons, which is improved here. Further, the error messages
are clarified and include more information.

Add `channel_keys_id` to `SpendableOutputDescriptor::StaticOutput`

In 7f0fd868ad4e8072440f1eb79e78894de1629157, `channel_keys_id` was
added as an argument to `SignerProvider::get_destination_script`,
allowing implementors to generate a new script for each channel.

This is great, however users then have no way to re-derive the
corresponding private key when they ultimately receive a
`SpendableOutputDescriptor::StaticOutput`. Instead, they have to
track all the addresses as they derive them separately. In many
cases this is fine, but we should support both deployments, which
we do here by simply including the missing `channel_keys_id` for
the user.

Merge pull request #2744 from rmalonson/destinationscript

Add channel_keys_id as param in get_destination_script to support gen…

Merge pull request #2675 from yellowred/delayed_payment_key_types

Implement struct wrappers for Payment, DelayedPayment, HTLC and Revocation channel keys

Add channel_keys_id as param in get_destination_script

This enables implementers to generate a different destination script for each channel.

Implement struct wrappers for channel key types to avoid confusion.

Currently all channel keys and their basepoints exist uniformly as
`PublicKey` type, which not only makes in harder for a developer to
distinguish those entities, but also does not engage the language
type system to check if the correct key is being used in any
particular function.

Having struct wrappers around keys also enables more nuanced
semantics allowing to express Lightning Protocol rules in language.
For example, the code allows to derive `HtlcKey` from
`HtlcBasepoint` and not from `PaymentBasepoint`.

This change is transparent for channel monitors that will use the
internal public key of a wrapper.

Payment, DelayedPayment, HTLC and Revocation basepoints and their
derived keys are now wrapped into a specific struct that make it
distinguishable for the Rust type system. Functions that require a
specific key or basepoint should not use generic Public Key, but
require a specific key wrapper struct to engage Rust type
verification system and make it more clear for developers which
key is used.

Merge pull request #2685 from tnull/2022-12-add-electrum-sync

Add electrum support to `lightning-transaction-sync`

Merge pull request #2741 from shaavan/issue-2215

Explicitly reject routes that double-back

Merge pull request #2746 from TheBlueMatt/2023-11-bitcoin-0.30-followups

Drop panic if rust-bitcoin adds a new Network

Remove now-redundant checks in BOLT12 `Invoice` fallback addresses

Now that we use the `rust-bitcoin` `WitnessProgram` to check our
addresses, we can just rely on it, rather than checking the program
length and version.

Drop panic if `rust-bitcoin` adds a new `Network`

`rust-bitcoin` 0.30 added `#[non_exhaustive]` to the `Network`
enum, allowing them to "add support" for a new network type without
a major version change in the future. When upgrading, we added a
simple `unreachable` for the general match arm, which would break
in a minor version change of `rust-bitcoin`.

While it seems [possible rust-bitcoin will change
this](https://github.com/rust-bitcoin/rust-bitcoin/issues/2225),
we still shouldn't ba panicking, which we drop here in favor of a
`debug_assert`ion, and a default value.

Add test for PathParameterError introduced in previous commit

- Also modify the unwrap_send_err!() macro to handle the
  PathParameterError

Use `esplora-client`'s `async-https-rustls` feature

Now that we upgraded `esplora-client` to 0.6 we can use
`async-https-rustls` instead of manually overriding the `reqwest`
dependency.

DRY up Esplora/Electrum `integration_tests`

Add Electrum integration test

Implement `ElectrumSyncClient`

Set `pending_sync` when last-minute check fails in Esplora

Move `sync_` methods to `SyncState`

Improve `EsploraSyncClient` test coverage

In particular, we now test `register_output` functionality, too.

Improve `EsploraSyncClient` logging

We give some more information while reducing the log levels to make the
logging less spammy.

We also convert one safe-to-unwrap case from returning an error to
unwrapping the value.

Use upstream `TestLogger` util in tx sync tests

Return confirmation height via `Confirm::get_relevant_txids`

We previously included the block hash, but it's also useful to include
the height under which we expect the respective transaction to be
confirmed.

Merge pull request #2740 from wpaulino/rust-bitcoin-30-update

Update to rust-bitcoin v0.30.2

Remove nightly warnings

Bump rust-bitcoin to v0.30.2