Stop cleaning monitor updates on new block connect

Previously, we used to cleanup monitor updates at both consolidation
threshold and new block connects. With this change we will only
cleanup when our consolidation criteria is met. Also, we remove
monitor read from cleanup logic, in case of update consolidation.
Note: In case of channel-closing monitor update, we still need to
read the old monitor before persisting the new one in order to
determine the cleanup range.

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.

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

Explicitly reject routes that double-back

- If a path within a route passes through the same channelID twice,
  that shows the path is looped and will be rejected by nodes.
- Add a check to explicitly reject such payment before trying to send
  them.

Merge pull request #2700 from Evanfeenstra/pub-htlc-routing

peel_payment_onion static fn in channelmanager

Merge pull request #2730 from benthecarman/invoice-utils

Add some public utilities to `lightning_invoice`

InboundOnionErr fields public

Have Invoice Description use UntrustedString

Make invoice fields public

Merge pull request #2696 from TheBlueMatt/2023-10-no-chan-feerate-upper-bound

Drop non-anchor channel fee upper bound limit entirely

Merge pull request #2727 from TheBlueMatt/2023-11-better-bolt11-utils

Replace maze of BOLT11 payment utilities with parameter generators

remove obsolete comment

peel_payment_onion static fn in channelmanager

Merge pull request #2529 from TheBlueMatt/2023-08-shutdown-remove-early-sign

Don't send init `closing_signed` too early after final HTLC removal

Merge pull request #2726 from shaavan/issue2712

Log the error, when trying to forward the intercepted HTLC, but the channel is not found

Log the error, when trying to forward the intercepted HTLC, but the

channel is not found

Merge pull request #2716 from TheBlueMatt/2023-11-hash-if-eq

`derive(Hash)` for P2P messages

`derive(Hash)` for P2P messages

In other languages (Java and C#, notably), overriding `Eq` without
overriding `Hash` can lead to surprising or broken behavior. Even
in Rust, its usually the case that you actually want both. Here we
add missing `Hash` derivations for P2P messages, to at least
address the first pile of warnings the C# compiler dumps.

Rely on const generic big arrays for `PartialEq` in msgs

Implementation of standard traits on arrays longer than 32 elements
was shipped in rustc 1.47, which is below our MSRV of 1.48 and we
can use to remove some unnecessary manual implementation of
`PartialEq` on `OnionPacket`.

Merge pull request #2544 from optout21/splicing-msgs0

Add Splicing (and Quiescence) wire message definitions

Merge pull request #2732 from arik-so/2023/11/update-musig2-dep

Update MuSig2 dependency for Hash trait derivation.

Merge pull request #2708 from TheBlueMatt/2023-11-less-graph-memory-frag

Reduce common allocations across the codebase

Update MuSig2 dependency for Hash trait derivation.

Merge pull request #2715 from valentinewallace/2023-11-skimmed-fees

Complete underpaying HTLCs support

Drop old `expiry_time_from_unix_epoch` helper in expiry time lookup

Since there's a much simpler way to go about it with
`Bolt11Invoice::expires_at`.

Merge pull request #2722 from benthecarman/dust-overflow

Fix potential cases where max_dust_htlc_exposure_msat overflows

Don't send init `closing_signed` too early after final HTLC removal

If we remove an HTLC (or fee update), commit, and receive our
counterparty's `revoke_and_ack`, we remove all knowledge of said
HTLC (or fee update). However, the latest local commitment
transaction that we can broadcast still contains the HTLC (or old
fee), thus we are not eligible for initiating the `closing_signed`
negotiation if we're shutting down and are generally expecting a
counterparty `commitment_signed` immediately.

Because we don't have any tracking of these updates in the `Channel`
(only the `ChannelMonitor` is aware of the HTLC being in our latest
local commitment transaction), we'd previously send a
`closing_signed` too early, causing LDK<->LDK channels with an HTLC
pending towards the channel initiator at the time of `shutdown` to
always fail to cooperatively close.

To fix this race, we add an additional unpersisted bool to
`Channel` and use that to gate sending the initial `closing_signed`.

Drop non-anchor channel fee upper bound limit entirely

Quite a while ago we added checks for the total current dust
exposure on a channel to explicitly limit dust inflation attacks.
When we did this, we kept the existing upper bound on the channel's
feerate in place. However, these two things are redundant - the
point of the feerate upper bound is to prevent dust inflation, and
it does so in a crude way that can cause spurious force-closures.

Here we simply drop the upper bound entirely, relying on the dust
inflation limit to prevent dust inflation instead.

Impl display for invoice fields

Replace maze of BOLT11 payment utilities with parameter generators

`lightning-invoice` was historically responsible for actually
paying invoices, handling retries and everything. However, that
turned out to be buggy and hard to maintain, so the payment logic
was eventually moved into `ChannelManager`. However, the old
utilites remain.

Because our payment logic has a number of tunable parameters and
there are different ways to pay a BOLT11 invoice, we ended up with
six different methods to pay or probe a BOLT11 invoice, with more
requested as various options still were not exposed.

Instead, here, we replace all six methods with two simple ones
which return the arguments which need to be passed to
`ChannelManager`. Those arguments can be further tweaked before
passing them on, allowing more flexibility.

Stop writing signer data as a part of channels

This breaks backwards compatibility with versions of LDK prior to
0.0.113 as they expect to always read signer data.

This also substantially reduces allocations during `ChannelManager`
serialization, as we currently don't pre-allocate the `Vec` that
the signer gets written in to. We could alternatively pre-allocate
that `Vec`, but we've been set up to skip the write entirely for a
while, and 0.0.113 was released nearly a year ago. Users
downgrading to LDK 0.0.112 and before at this point should not be
expected.

Avoid allocating when checking gossip message signatures

When we check gossip message signatures, there's no reason to
serialize out the full gossip message before hashing, and it
generates a lot of allocations during the initial startup when we
fetch the full gossip from peers.

Avoid a `tokio::mpsc::Sender` clone for each P2P send operation

Whenever we go to send bytes to a peer, we need to construct a
waker for tokio to call back into if we need to finish sending
later. That waker needs some reference to the peer's read task to
wake it up, hidden behind a single `*const ()`. To do this, we'd
previously simply stored a `Box<tokio::mpsc::Sender>` in that
pointer, which requires a `clone` for each waker construction. This
leads to substantial malloc traffic.

Instead, here, we replace this box with an `Arc`, leaving a single
`tokio::mpsc::Sender` floating around and simply change the
refcounts whenever we construct a new waker, which we can do
without allocations.

Avoid re-allocating to encrypt gossip messages when forwarding

When we forward gossip messages, we store them in a separate buffer
before we encrypt them (and commit to the order in which they'll
appear on the wire). Rather than storing that buffer encoded with
no headroom, requiring re-allocating to add the message length and
two MAC blocks, we here add the headroom prior to pushing it into
the gossip buffer, avoiding an allocation.

Fix potential cases where max_dust_htlc_exposure_msat overflows

Fix `data_loss_protect` test to actually test DLP

The data loss protect test was panicking in a message assertion
which should be passing, but because the test was marked only
`#[should_panic]` it was being treated as a successful outcome.
Instead, we use `catch_unwind` on exactly the line we expect to
panic to ensure we are hitting the right one.

Link to LSP spec in accept_underpaying_htlcs config

Include counterparty skimmed fees in PaymentClaimed event.

Merge pull request #2702 from G8XSU/libFuzzer

Update fuzzing instructions for libFuzzer/cargo-fuzz

Use `VecDeque`, rather than `LinkedList` in peer message buffering

When buffering outbound messages for peers, `LinkedList` adds
rather substantial allocation overhead, which we avoid here by
swapping for a `VecDeque`.

Avoid unnecessarily alloc'ing a new buffer when decrypting messages

When decrypting P2P messages, we already have a read buffer that we
read the message into. There's no reason to allocate a new `Vec` to
store the decrypted message when we can just overwrite the read
buffer and call it a day.

Add an option to in-place decrypt with `ChaCha20Poly1305`

In the next commit we'll use this to avoid an allocation when
deserializing messages from the wire.

Merge pull request #2714 from TheBlueMatt/2023-11-one-less-alloc

Avoid an unnecessary allocation in `TaggedHash`

Add Splicing (and Quiescence) wire message definitions

Avoid an unnecessary allocation in `TaggedHash`

A well-formed tag is always a constant, so allocating to store it
is unnecessary when we can just make the tag a `&'static str`.

Merge pull request #2687 from orbitalturtle/signature-data-enum

Expose more granular data in TaggedHash struct

Merge pull request #2677 from Evanfeenstra/public-onion-utils

public create_payment_onion in onion_utils

Pre-allocate the full `Vec` prior to serializing as a `Vec<u8>`

We end up generating a substantial amount of allocations just
doubling `Vec`s when serializing to them, and our
`serialized_length` method is generally rather effecient, so we
just rely on it and allocate correctly up front.

expose more granular data in TaggedHash struct

Expose tag and merkle root fields in the TaggedHash struct.

refactor to remove message_digest

We change the Bolt12Invoice struct to carry a tagged hash. Because
message_digest is then only used in one place, we can inline it in
the TaggedHash constructor.

Update fuzzing instructions for libFuzzer/cargo-fuzz

export create_onion_message and peel_onion_message from ln::onion_message

public create_payment_onion in onion_utils

Merge pull request #2699 from mhrheaume/mhr/temporary_channel_id

Added `temporary_channel_id` to `create_channel`.

Avoid unnecessarily overriding `serialized_length`

...as LLVM will handle it just fine for us, in most cases.

Pre-allocate send buffer when forwarding gossip

When forwarding gossip, rather than relying on Vec doubling,
pre-allocate the message encoding buffer.

Prefer `Writeable.encode()` over `VecWriter` use

It does the same thing and its much simpler.

Reduce on-startup heap frag due to network graph map/vec doubling

When we're reading a `NetworkGraph`, we know how many
nodes/channels we are reading, there's no reason not to
pre-allocate the `IndexedMap`'s inner `HashMap` and `Vec`, which we
do here.

This seems to reduce on-startup heap fragmentation with glibc by
something like 100MiB.

Added `temporary_channel_id` to `create_channel`.

By default, LDK will generate the initial temporary channel ID for you.
However, in certain cases, it's desirable to have a temporary channel ID
specified by the caller in case of any pre-negotiation that needs to
happen between peers prior to the channel open message. For example, LND
has a `FundingShim` API that allows for advanced funding flows based on
the temporary channel ID of the channel.

This patch adds support for optionally specifying the temporary channel
ID of the channel through the `create_channel` API.

Merge pull request #2558 from waterson/pr-2554

Handle retrying sign_counterparty_commitment failures

Merge pull request #2641 from alexanderwiederin/2585-preflight-test-coverage

#2585 Preflight Test Coverage

Add basic async signer tests

Adds a `get_signer` method to the context so that a test can get ahold of the
channel signer. Adds a `set_available` method on the `TestChannelSigner` to
allow a test to enable and disable the signer: when disabled some of the
signer's methods will return `Err` which will typically activate the error
handling case. Adds a `set_channel_signer_available` function on the test
`Node` class to make it easy to enable and disable a specific signer.

Adds a new `async_signer_tests` module:

* Check for asynchronous handling of `funding_created` and `funding_signed`.
* Check that we correctly resume processing after awaiting an asynchronous
  signature for a `commitment_signed` event.
* Verify correct handling during peer disconnect.
* Verify correct handling for inbound zero-conf.

Handle retrying sign_counterparty_commitment inb funding failures

If sign_counterparty_commitment fails (i.e. because the signer is
temporarily disconnected), this really indicates that we should
retry the message sending which required the signature later,
rather than force-closing the channel (which probably won't even
work if the signer is missing).

This commit adds retrying of inbound funding_created signing
failures, regenerating the `FundingSigned` message, attempting to
re-sign, and sending it to our peers if we succeed.