Add missing UnknownRequiredFeatures tests

Common offers test_utils module

Move utility functions used across all offers modules into a common
module. Avoids duplicating larger utilities such as payment_path across
more than one module.

Merge pull request #2198 from TheBlueMatt/2023-04-fewer-disables

Only disable channels ~10 min after disconnect, rather than one

Only disable channels ~10 min after disconnect, rather than one

We correctly send out a gossip channel disable update after one
full time tick being down (1-2 minutes). This is pretty nice in
that it avoids nodes trying to route through our nodes too often
if they're down. Other nodes have a much longer time window,
causing them to have much less aggressive channel disables. Sadly,
at one minute it's not super uncommon for tor nodes to get disabled
(once a day or so on two nodes I looked at), and this causes the
lightning terminal scorer to consider the LDK node unstable (even
though it's the one doing the disabling - so is online). This
causes user frustration and makes LDK look bad (even though it's
probably failing fewer payments).

Given this, and future switches to block-based `channel_update`
timestamp fields, it makes sense to go ahead and switch to delaying
channel disable announcements for 10 minutes. This puts us more in
line with other implementations and reduces gossip spam, at the
cost of less reliable payments.

Fixes #2175, at least the currently visible parts.

Set `channel_update` disable bit based on staged even for onions

When generating a `channel_update` either in response to a fee
configuration change or an HTLC failure, we currently poll the
channel to check if the peer's connected when setting the disabled
bit in the `channel_update`. This could cause cases where we set
the disable bit even though the peer *just* disconnected, and don't
generate a followup broadcast `channel_update` with the disabled
bit unset.

While a node generally shouldn't rebroadcast a `channel_update` it
received in an onion, there's nothing inherently stopping them from
doing so. Obviously in the fee-update case we expect the message to
propagate.

Luckily, since we already "stage" disable-changed updates, we can
check the staged state and use that to set the disabled bit in all
`channel_update` cases.

Merge pull request #2138 from swilliamson5/replace-our-max-htlcs-constant

Replace `OUR_MAX_HTLCS` with config knob

Merge pull request #2196 from wpaulino/ci-ignore-master-cancel-prev

Prevent unnecessary CI workflow runs

Merge pull request #2195 from TheBlueMatt/2023-04-115-bindings-upstream

Cancel in-progress jobs on updated push

At times, PRs can go through multiple pushes in a short amount of time,
spawning a workflow run for each. Most of the time, there's no need to
let the previous jobs running if the code itself has changed (e.g., via
a force push), and we'd benefit from having those slots be used by other
PRs/branches instead.

Ignore workflow runs on master branch

This master branch is just an alias to the main branch for legacy
reasons, so there's no need to run workflows on both branches.

Mark the invoice `Network` getter no-export

...as it is redundant with the `currency` getter if we're not using
the rust-bitcoin types natively.

Merge pull request #2177 from TheBlueMatt/2023-04-test-function-generics

Genericize Test Functions

Merge pull request #2191 from TheBlueMatt/2023-04-fix-bucket-deser

Fix deserialization of u16 arrays

Merge pull request #2187 from benthecarman/invoice-serde-no-std

Replace OUR_MAX_HTLCS constant with config knob
holder_max_accepted_htlcs. Set upper bound of 483

Writes an even TLV if the value isn't 50

Fix deserialization of u16 arrays

u16 arrays are used in the historical liquidity range tracker.
Previously, we read them without applying the stride multiple,
reading bytes repeatedly and at an offset, corrupting data as we
go.

This applies the correct stride multiplayer fixing the issue.

Add CI test for compile no-std serde lightning-invoice

Fix compiling lightning-invoice for no-std + serde

Merge pull request #2172 from TheBlueMatt/2023-04-fix-panicy-debug-assert

Remove a race-y debug assertion in new channel update handling

Merge pull request #2180 from benthecarman/impl-pk-to-node-id

Implement to and from for PublicKey and NodeId

Impl FromStr for NodeId

Merge pull request #2179 from benthecarman/use-node-alias-type

Use NodeAlias type in NodeAnnouncement

Move some additional test macros into functions

This marginally reduces the quantity of code compiled in tests
further.

Introduce traits to make test utils generic across the `CM` Holder

In our test utilities, we generally refer to a `Node` struct which
holds a `ChannelManager` and a number of other structs. However, we
use the same utilities in benchmarking, where we have a different
`Node`-like struct. This made moving from macros to functions
entirely impossible, as we end up needing multiple types in a given
context.

Thus, here, we take the pain and introduce some wrapper traits
which encapsulte what we need from `Node`, swapping some of our
macros to functions.

Use NodeAlias type in NodeAnnouncement

Implement to and from for PublicKey and NodeId

DRY the event handling in `ChannelManager`

In the coming commits we'll add some additional complexity to the
event handling flows, so best to DRY them up before we get there.

Merge pull request #2142 from alecchendev/2023-03-expose-fail-reason-in-payment-failure

Expose a failure reason in `PaymentFailed`

Add reason to `Event::PaymentFailed`

This includes adding a reason to `PendingOutboundPayment::Abandoned` and
using that reason when pushing an `Event::PaymentFailed`.

Merge pull request #2173 from benthecarman/convert-currency-to-netowkr

Convert Network to and from Currency

Convert Network to and from Currency

Remove a race-y debug assertion in new channel update handling

In 6090d9e6a862a2010eb80be56b7449947bc08374 we swapped out old
debug assertions that checked that a lock was `try_lock`able to
test that certain locks weren't held when we needed to be able to
take them in some near branch. However, another slipped in after in
the `ChannelMonitorUpdate` handling rework, which is replaced with
the new debug assertions here.

Merge pull request #2161 from benthecarman/prune-stale-channels-rgs

Prune stale channels from network graph after RGS sync.

Merge pull request #2158 from TheBlueMatt/2023-04-handle_err_more-check

Test for extra locks held in `handle_error` unconditionally

Merge pull request #2023 from futurepaul/fallback-to-address

add `Fallback` getter that returns `Address`

Create `PaymentFailureReason` enum

Merge pull request #2170 from TheBlueMatt/2023-04-silent-merge-conflict

Fix silent merge conflict between new test and payment refactor

Merge pull request #2162 from jkczyz/2023-04-invoice-hash

Fix silent merge conflict between new test and payment refactor

Merge pull request #2148 from TheBlueMatt/2023-04-claim-from-closed

Allow claiming a payment if a channel with an HTLC has closed

Merge pull request #2139 from TheBlueMatt/2023-03-metadata-prefactors

Add a new `RecipientOnionFields` and replace `PaymentSecret` with it

Merge pull request #2165 from wpaulino/fix-bp-channel-pending-panic-flake

Use signal for handling ChannelPending in test_background_event_handling

Split up comically long error return

Expose a BOLT 12 Invoice's signable_hash

This is useful as an identifier for downstream clients like VLS.

Expose a BOLT 11 Invoice's signable_hash

Otherwise, an Invoice must first be converted to a SignedRawInvoice to
obtain the hash.

Linkify lightning-invoice docs

Lift std check to function definition

Use signal for handling ChannelPending in test_background_event_handling

This fixes two potential panics within the test if the
`BackgroundProcessor` for `nodes[0]` consumed the `ChannelPending` event
prior to us consuming it manually in `end_open_channel`. The first panic
would happen within the event handler, since `ChannelPending` was not
being handled. The second panic would happen upon expecting the
`ChannelPending` event after handling `nodes[1]`'s `funding_signed` if
the `BackgroundProcessor` handled the event first. To ensure we still
reliably receive a `ChannelPending` event once possible, we let the
`BackgroundProcessor` consume the event and notify it.

Merge pull request #2163 from TheBlueMatt/2023-04-less-lock

Avoid holding a `per_peer_state` lock while claiming from a monitor

Prune stale channels from network graph after RGS sync

Add a `claim_deadline` field to `PaymentClaimable` with guarantees

Now that we guarantee `claim_payment` will always succeed we have
to let the user know what the deadline is. We still fail payments
if they haven't been claimed in time, which we now expose in
`PaymentClaimable`.

Avoid holding a `per_peer_state` lock while claiming from a monitor

There's no reason to hold a lock on `per_peer_state` while we're
claiming from a since-closed channel via a `ChannelMonitorUpdate`,
which we stop doing here.

Merge pull request #2101 from TheBlueMatt/2023-03-one-less-sig

Support future removal of redundant per-HTLC signatures in `CMU`s

`Fallback`: add `Address` getter and use bitcoin types

Test for extra locks held in `handle_error` unconditionally

`handle_error` must be called without `per_peer_state` mutex or
`pending_events` mutex locks held or we may risk deadlocks.
Previously we checked this in debug builds in the error path, but
not in the success path.

As it turns out, `funding_transaction_generated`'s error path does
hold a `per_peer_state` lock, which we fix here as well as move the
tests to happen unconditionally.

Merge pull request #2145 from TheBlueMatt/2023-04-async-bp-cleanups

Add test coverage of async BP and fix minor bug

Correct documentation of `payment_id` in events

Pipe the new `RecipientOnionFields` through send pipeline

This passes the new `RecipientOnionFields` through the internal
sending APIs, ensuring we have access to the full struct when we
go to construct the sending onion so that we can include any new
fields added there.

Add a `RecipientOnionFields` argument to spontaneous payment sends

While most lightning nodes don't (currently) support providing a
payment secret or payment metadata for spontaneous payments,
there's no specific technical reason why we shouldn't support
sending those fields to a recipient.

Further, when we eventually move to allowing custom TLV entries in
the recipient's onion TLV stream, we'll want to support it for
spontaneous payments as well.

Here we simply add the new `RecipientOnionFields` struct as an
argument to the spontaneous payment send methods. We don't yet
plumb it through the payment sending logic, which will come when we
plumb the new struct through the sending logic to replace the
existing payment secret arguments.

Replace `PaymentSecret` with `RecipientOnionFields` in the pub API

This moves the public payment sending API from passing an explicit
`PaymentSecret` to a new `RecipientOnionFields` struct (which
currently only contains the `PaymentSecret`). This gives us
substantial additional flexibility as we look at add both
`PaymentMetadata`, a new (well, year-or-two-old) BOLT11 invoice
extension to provide additional data sent to the recipient.

In the future, we should also add the ability to add custom TLV
entries in the `RecipientOnionFields` struct.

Remove the `PaymentSecret` field from `HTLCSource::OutboundRoute`

Many of the fields in `HTLCSource::OutboundRoute` are used to
rebuild the pending-outbound-payment map on reload if the
`ChannelManager` was not serialized though `ChannelMonitor`(s)
were after an HTLC was sent. As of 0.0.114, however, such payments
are not retryable without allowing them to fail and doing a full,
fresh, send.

Thus, some of the fields can be safely removed - we only really
care about having enough information to provide the user a failure
event, not being able to retry.

Here we drop one such field - the `payment_secret`, making our
`ChannelMonitorUpdate`s another handful of bytes smaller.

Allow claiming a payment if a channel with an HTLC has closed

Previously, LDK would refuse to claim a payment if a channel on
which the payment was received had been closed between when the
HTLC was received and when we went to claim it. This makes sense in
the payment case - why pay an on-chain fee to claim the HTLC when
presumably the sender may retry later. Long ago it also reduced
total code in the claim pipeline.

However, this doesn't make sense if you're trying to do an atomic
swap or some other protocol that requires atomicity with some other
action - if your money got claimed elsewhere you need to be able to
claim the HTLC in lightning no matter what. Further, this is an
over-optimization - there should be a very, very low likelihood
that a channel closes between when we receive the last HTLC for a
payment and the user goes to claim the payment. Since we now have
code to handle this anyway we should allow it.

Fixes #2017.

Add an async version of BP's test_channel_manager_persist_error

This gives us coverage of an async BP returning an error.

Make BP's `not_pruning_network_graph_until...` test dual async-sync

Make BP's `test_payment_path_scoring` dual sync/async.

This finally gives us a bit of test coverage of the async BP, which
was embarrassingly missing until now.

Ensure `background-processor` exits after any sleep future says to

If the user's sleep future passed to an async background processor
only returns true for exiting once and then reverts back to false,
we should exit anyway when we get a chance to. We do to this here
by always ensuring we check the exit flag even when only polling
sleep futures with no intent to (yet) exit. This is utilized in the
tests added in the coming commit(s).

Don't immediately exit BP if `ChannelManager` is persistable

If `ChannelManager` is persistable before the async background
processor even starts, it may not even get around to overwriting
the `should_exit` flag before testing it, and the default value is
(incorrectly) true, causing an immediate unconditional exit.

The default value should simply be false.

Fixes #2140

Make `lightning-background-processor` test failures more debugable

Instead of asserting a `Result` `is_ok`, we should always simply
`unwrap` to get a backgrace, and we should avoid doing so if the
thread is already panicking.

Merge pull request #2150 from TonyGiorgio/esplora-0.4

lightning-transaction-sync: Bump esplora to 0.4

Merge pull request #2147 from TheBlueMatt/2023-04-rgs-log-some

Add some trivial logging during RGS update processing.

lightning-transaction-sync: Bump esplora to 0.4

Merge pull request #2005 from arik-so/2023-01-taproot-message-types

Update messages for Taproot types.

Add some trivial logging during RGS update processing.

Rather than being totally silent, we need to at least note that we
are processing an RGS update when doing so in the logs, which we do
here.

Fixes #1981.

Add Taproot CI test.

Update the `RevokeAndACK` message for Taproot support.

Update the `CommitmentSigned` message for Taproot support.

Update the `FundingSigned` message for Taproot support.

Update the `FundingCreated` message for Taproot support.

Update the `AcceptChannel` message for Taproot support.

Introduce MuSig2-related types for Taproot channels.

Merge pull request #2090 from TheBlueMatt/2023-03-mon-wake-bp

Wake background-processor on async monitor update completion

Merge pull request #2098 from tnull/2023-03-add-channel-pending-event

Add `ChannelPending` event emitted upon `funding_signed`

Merge pull request #2143 from get10101/chore/convenient-confirm

Implement `chain::Confirm` without mandating any owned values

Add `ChannelPending` event emitted upon `funding_signed`

Currently, users don't have good way of being notified when channel open
negotiations have succeeded and new channels are pending confirmation on
chain. To this end, we add a new `ChannelPending` event that is emitted
when send or receive a `funding_signed` message, i.e., at the last
moment before waiting for the confirmation period.

We track whether the event had previously been emitted in `Channel` and
remove it from `internal_funding_created` entirely. Hence, we now
only emit the event after ChannelMonitorUpdate completion, or upon
channel reestablish. This mitigates a race condition where where we
wouldn't persist the event *and* wouldn't regenerate it on restart,
therefore potentially losing it, if async CMU wouldn't complete before
ChannelManager persistence.

Expose an option to substantially reduce sleep time in futures BP

Some users have suggested that waking every 100ms can be
CPU-intensive in deployments with hundreds or thousands of nodes
all running on the same machine. Thus, we add an option to the
futures-based `background-processor` to avoid waking every 100ms to
check for iOS having backgrounded our app and cut our TCP sockets.

This cuts the normal sleep time down from 100ms to 10s, for those
who turn it on.

Wake the background processor if an async monitor update completes

If the `ChainMonitor` gets an async monitor update completion, this
means the `ChannelManager` needs to be polled for event processing.
Here we wake it using the new multi-`Future`-await `Sleeper`, or
the existing `select` block in the async BP.

Fixes #2052.

Drop the dummy no-std `Condvar` which never sleeps

In `no-std`, we exposed `wait` functions which rely on a dummy
`Condvar` which never actually sleeps. This is somwhat nonsensical,
not to mention confusing to users. Instead, we simply remove the
`wait` methods in `no-std` builds.

Move the pub `wait` methods from `ChannelManager` to `Future`

Rather than having three ways to await a `ChannelManager` being
persistable, this moves to just exposing the awaitable `Future` and
having sleep functions on that.

Implement the ability to block on multiple futures at once

In the next commits we'll be adding a second notify pipeline - from
the `ChainMonitor` back to the background processor. This will
cause the `background-processor` to need to await multiple wakers
at once, which we cannot do in the current scheme without taking on
a full async runtime.

Building a multi-future waiter isn't so bad, and notably will allow
us to remove the existing sleep pipeline entirely, reducing the
complexity of our wakers implementation by only having one notify
path to consider.

Do not bound callbacks by `Send` when building for `no-std`

`Send` is rather useless on a `no-std` target - we don't have
threads and are just needlessly restricting ourselves, so here we
skip it for the wakers callback.

Add `CondVar::wait_{timeout_,}while` to `debug_sync`

These are useful, but we previously couldn't use them due to our
MSRV. Now that we can, we should use them, so we expose them via
our normal debug_sync wrappers.

Implement chain::Confirm without mandating any owned values

Correct `lightning-net-tokio` documentation, remove stale example

The `lightning-net-tokio` crate-level example contained a carryover
from when it was the primary notifier of the background processor
and now just shows an "example" of creating a method to call
another method with the same parameters and then do event
processing (which doesn't make sense, the BP should do that).

Instead, the examples are simply removed and the documentation is
tweaked to include recent changes.

Merge pull request #2141 from TheBlueMatt/2023-03-fuck-rust

Drop `futures` dependency from `lightning-block-sync`

Remove `futures` dependency in `lightning-background-processor`

As `futures` apparently makes no guarantees on MSRVs even in patch
releases we really can't rely on it at all, and while it currently
has an acceptable MSRV without the macros feature, its best to just
remove it wholesale.

Luckily, removing it is relatively trivial, even if it requires
the most trivial of unsafe tags.

Replace `futures` `select` with our own select enum to fix MSRV

`futures` recently broke our MSRV by bumping the `syn` major
version in a patch release. This makes it impractical for us to
use, instead here we replace the usage of its `select_biased` macro
with a trivial enum.

Given its simplicity we likely should have done this without ever
taking the dependency.

Avoid connection-per-RPC-call again by caching connections

In general, only one request will be in flight at a time in
`lightning-block-sync`. Ideally we'd only have one connection, but
without using the `futures` mutex type.

Here we solve this narrowly for the one-request-at-a-time case by
caching the connection and takeing the connection out of the cache
while we work on it.

Drop `futures` dependency from `lightning-block-sync`

Some how I'd understood that `futures` had reasonable MSRV
guarantees (e.g. at least Debian stable), but apparently that isn't
actually the case, as they bumped it to upgrade to syn (with
apparently no actual features or bugfixes added as a result?) with
no minor version bump or any available alternative (unlike Tokio,
which does LTS releases).

Luckily its relatively easy to just drop the `futures` dependency -
it means a new connection for each request, which is annoying, but
certainly not the end of the world, and its easier than trying to
deal with pinning `futures`.

See https://github.com/rust-lang/futures-rs/pull/2733

Merge pull request #2136 from marctyndel/2023-03-paymentforwarded-expose-amount-forwarded

Expose amount forwarded in `PaymentForwarded` event

Merge pull request #2059 from wpaulino/broadcast-missing-anchors-event

Queue BackgroundEvent to force close channels upon ChannelManager::read