Fix build on supported platforms due to `log` breakage

The `log` crate decided to break support for rustc 1.48 (Debian
bullseye) the day the next release of Debian comes out, obviously
before anyone has had a chance to upgrade to the new Debian
bookworm (at https://github.com/rust-lang/log/pull/543). Thus, we
have to manually pin it back to the previous release.

Sadly, the `log` crate is a transitive dependency of `tokio` until
0.20, which requires rustc 1.49. Luckily at least we won't have to
deal with this again, as `log` won't be a dependency of ours
anymore soon.

Merge pull request #2156 from alecchendev/2023-04-mpp-keysend

Support MPP Keysend

Add test for duplicate keysend payment

The logic has been changed around duplicate keysend payments such that
it's no longer explicitly clear that we reject duplicate keysend
payments now that we handle receiving multi-part keysends. This test
catches that. Note that this also tests that we reject MPP keysends when
our config states we should, and that we reject MPP keysends without
payemnt secrets when our config states we support MPP keysends.

Support receiving MPP keysend

This commit refactors a significant portion of the receive validation in
`ChannelManager::process_pending_htlc_forwards` now that we repurpose
previous MPP validation logic to accomodate keysends. This also removes
a previous restriction on claiming, as well as tests sending and
receiving MPP keysends.

Track MPP data while receiving keysends

This commit adds the field `payment_data: FinalOnionHopData` to
`ReceiveKeysend` which will allow us to check for payment secrets and
total amounts which is needed to support receiving MPP keysends. This
field is non-backwards compatible since we wouldn't be able to handle
an MPP keysend properly if we were to downgrade to a prior version.

We also no longer reject keysends with payment secrets if we support MPP
keysend.

Help users support sending MPP keysend

When routing a keysend payment, the user may want to signal to the
router whether to find multi-path routes in the
`PaymentParameters::for_keysend` helper, without going through manual
construction. Since some implementations do not support MPP keysend, we
have the user make the choice here rather than making it the default.

Some implementations will reject keysend payments with payment secrets,
so this commit also adds docs to `RecipientOnionFields` to communicate
this to the user.

Merge pull request #2334 from jkczyz/2023-06-bolt12-test-vectors

Update BOLT 12 test vectors

Merge pull request #2333 from benthecarman/chan-mon-bal-helper

Add helper for getting claimable balance

Merge pull request #2342 from vladimirfomene/2023-06-use-untrustedstring-in-error-logs

Use PrintableString for displaying errors in PeerManager

Include signature check in BOLT 12 signature test

The BOLT 12 test vectors had inadvertently left out a signature, but it
has since been added. Include a signature check in the corresponding
test for completeness.

Update BOLT 12 test vectors

The previous test vectors contained recurrences and older TLV types, and
therefore couldn't be parsed. Update the tests with the latest test
vectors from the spec and stop ignoring the tests.

Remove custom blinded path test vector

These were added to help debug an encoding issue. However, the encoding
code was moved to the blinded_path module. Additionally, the test vector
used an old TLV encoding.

Add helper for getting claimable balance

It is annoying to have to match across all the enums of `Balance` to
just pull out the `claimable_amount_satoshis` value. This helper makes
it easier if you just want to amount.

Use PrintableString for displaying errors in PeerManager

We currently just print "with non-ASCII error message"
to log when we see non-ASCII chars, but should instead
use our fancy PrintableString type to display the
untrusted string and ignore control chars.

Merge pull request #2312 from TheBlueMatt/2023-05-next-htlc-min-max

Avoid generating unpayable routes due to balance restrictions

Merge pull request #2305 from valentinewallace/2023-05-respect-hint-maxhtlc

Respect route hint `max_htlc` in pathfinding

Merge pull request #2330 from wvanlint/partial_config_updates

Support atomic partial updates to ChannelConfig

Slightly improve docs on `next_*_commit_tx_fee_msat`

Replace `send_htlc` amount checking with available balances

Now that the `get_available_balances` min/max bounds are exact, we
can stop doing all the explicit checks in `send_htlc` entirely,
instead comparing against the `get_available_balances` bounds and
failing if the amount is out of those bounds.

This breaks support for sending amounts below the dust limit if
there is some amount of dust exposure remaining before we hit our
cap, however we will no longer generate such routes anyway.

Ensure a 1:1 mapping of value sendable to send success in fuzzing

Now that the value available to send is expected to match the
success or failure of sending exactly, we should assert this in the
`chanmon_consistency` fuzzer.

In the next commit we'll actually rip the checks out of `send_htlc`
which will make this a somewhat less useful test, however fuzzing
on this specific commit can help to reveal bugs.

Consider dust exposure when assembling a route

When calculating the amount available to send for the next HTLC, if
we over-count we may create routes which are not actually usable.

Historically this has been an issue, which we resolve over a few
commits.

Here we consider how much adding one additional (dust) HTLC would
impact our total dust exposure, setting the new next-HTLC-minimum
field to require HTLCs be non-dust if required or set our next-HTLC
maximum if we cannot send a dust HTLC but do have some additional
exposure remaining.

We also add some testing when sending to ensure that send failures
are accounted for in our balance calculations.

Fixes #2252.

Add a next-outbound-HTLC minimum field to chan details and use it

In the coming commits, in order to ensure all routes we generate
are usable, we'll start calculating the next-HTLC minimum for our
channels and using it in the router. Here we set this up by adding
an always-0 field for it in `ChannelDetails` and use it when
routing.

Consider counterparty commitment tx fees when assembling a route

When calculating the amount available to send for the next HTLC, if
we over-count we may create routes which are not actually usable.

Historically this has been an issue, which we resolve over a few
commits.

Here we consider whether one additional HTLC's commitment tx fees
would result in the counterparty's commitment tx fees being greater
than the reserve we've picked for them and, if so, limit our next
HTLC value to only include dust HTLCs.

We also add some testing when sending to ensure that send failures
are accounted for in our balance calculations.

This, and the previous few commits, fixes #1126.

Support atomic partial updates to ChannelConfig

Merge pull request #2340 from TheBlueMatt/2023-06-fix-docs

Remove spurious docs which imply you cannot retry a failed payment

Account for used liquidity in first hops when processing route hints

.. in get_route.

Abide by route hint max_htlc in pathfinding

Remove spurious double comma in documentation

Remove spurious docs which imply you cannot retry a failed payment

If a payment (fully) fails, users are free to retry it, its only
once a payment succeeds that a user must never retry it.

Merge pull request #2290 from upjohnc/2240_replace_vectors_with_iterators

Set return type to Iterator for functions in file: `lightning-invoice/src/utils.rs` : issue #2240

Merge pull request #2329 from dunxen/2023-05-initgenesischeck

Add support for `networks` field in `Init` message

Send and handle `networks` field in `Init` messages

If the `networks` field is present in a received `Init` message, then
we need to make sure our genesis chain hash matches one of those, otherwise
we should disconnect the peer.

We now also always send our genesis chain hash in `Init` messages to
our peers.

Add `networks` TLV to `Init`'s TLV stream

This was a fairly old introduction to the spec to allow nodes to indicate
to their peers what chains they are interested in (i.e. will open channels
and gossip for).

We don't do any of the handling of this message in this commit and leave
that to the very next commit, so the behaviour is effectively the same
(ignore networks preference).

Merge pull request #2332 from danielgranhao/fix/wrong-docs-link-channel-manager-send-payment

Fix wrong link in `ChannelManager::send_payment()` docs

Remove duplicate BOLT 12 test vector

Fix wrong link in `ChannelManager::send_payment()` docs

Merge pull request #2328 from benthecarman/partial-eq-in-mem-signer

Impl PartialEq and Debug for InMemorySigner

Refactor lightning-invoice/src/utils.rs to yield iterators

- two functions refatored: `select_phantom_hints`, `sort_and_filter_channels`

Impl PartialEq and Debug for InMemorySigner

These are needed for being able to compare a
ChannelMonitor<InMemorySigner> and are just nice to haves for
developers.

Merge pull request #2167 from TheBlueMatt/2023-04-monitor-e-monitor-prep

Add infra to block ChannelMonitorUpdates on forwarded claims

Merge pull request #2324 from dunxen/2023-05-rgscheckgenesishash

Fail RGS data processing early if there is a chain hash mismatch

Adding rotate_through_iterators for select_phantom_hints refactor

- adding function to allow for select_phantom_hints to yield an iterator

Add infra to block `ChannelMonitorUpdate`s on forwarded claims

When we forward a payment and receive an `update_fulfill_htlc`
message from the downstream channel, we immediately claim the HTLC
on the upstream channel, before even doing a `commitment_signed`
dance on the downstream channel. This implies that our
`ChannelMonitorUpdate`s "go out" in the right order - first we
ensure we'll get our money by writing the preimage down, then we
write the update that resolves giving money on the downstream node.

This is safe as long as `ChannelMonitorUpdate`s complete in the
order in which they are generated, but of course looking forward we
want to support asynchronous updates, which may complete in any
order.

Here we add infrastructure to handle downstream
`ChannelMonitorUpdate`s which are blocked on an upstream
preimage-containing one. We don't yet actually do the blocking which
will come in a future commit.

Reapply pending `ChannelMonitorUpdate`s on startup

If a `ChannelMonitorUpdate` was created and given to the user but
left uncompleted when the `ChannelManager` is persisted prior to a
restart, the user likely lost the `ChannelMonitorUpdate`(s). Thus,
we need to replay them for the user, which we do here using the
new `BackgroundEvent::MonitorUpdateRegeneratedOnStartup` variant.

Process background events when taking the total_consistency_lock

When we generated a `ChannelMonitorUpdate` during `ChannelManager`
deserialization, we must ensure that it gets processed before any
other `ChannelMonitorUpdate`s. The obvious hook for this is when
taking the `total_consistency_lock`, which makes it unlikely we'll
regress by forgetting this.

Here we add that call in the `PersistenceNotifierGuard`, with a
test-only atomic bool to test that this criteria is met.

Handle `BackgroundEvent`s replaying non-closing monitor updates

`BackgroundEvent` was used to store `ChannelMonitorUpdate`s which
result in a channel force-close, avoiding relying on
`ChannelMonitor`s having been loaded while `ChannelManager`
block-connection methods are called during startup.

In the coming commit(s) we'll also generate non-channel-closing
`ChannelMonitorUpdate`s during startup, which will need to be
replayed prior to any other `ChannelMonitorUpdate`s generated from
normal operation.

In the next commit we'll handle that by handling `BackgroundEvent`s
immediately after locking the `total_consistency_lock`.

Merge pull request #2293 from wpaulino/disconnect-peers-timer-tick

Disconnect peers on timer ticks to unblock channel state machine

Make `AChannelManager` trait slightly more generic and always on

Rather than letting `AChannelManager` be bounded by all traits
being `Sized` we make them explicitly `?Sized`. We also make the
trait no longer test-only as it will be used in a coming commit.

Return the counterparty node_id as a part of a force-shutdown res

In the coming commits we'll need the counterparty node_id when
handling a background monitor update as we may need to resume
normal channel operation as a result. Thus, we go ahead and pipe it
through from the shutdown end, as it makes the codepaths
consistent.

Sadly, the monitor-originated shutdown case doesn't allow for a
required counterparty node_id as some versions of LDK didn't have
it present in the ChannelMonitor.

Move the `ShutdownResult` type alias to `channel.rs`

This allows us to make the `force_shutdown` definition less verbose

Fix `held_by_thread` in `no-std` to return instead of panicing

Our `no-std` locks simply panic if a lock cannot be taken as there
should be no lock contention in a single-threaded environment.
However, the `held_by_thread` debug methods were delegating to the
lock methods which resulted in a panic when asserting that a lock
*is* held by the current thread.

Instead, they are updated here to call the relevant `RefCell`
testing methods.

Merge pull request #2323 from ariard/2023-05-remove-ariard-pgp-key

Remove ariard key from the security team

Fail RGS data processing early if there is a chain hash mismatch

No point in doing any extra processing if we don't even have a match
for the chain hash.

Remove ariard key from the security team

Allow user to opt-in to accepting MPP keysend

To support receiving MPP keysends, we will add a new non-backward
compatible field to `PendingHTLCRouting::ReceiveKeysend`, which will
break deserialization of `ChannelManager` on downgrades, so we allow the
user choose whether they want to do this. Note that this commit only
adds the config flag, while full MPP support is added in later commits.

Disconnect peers on timer ticks to unblock channel state machine

At times, we've noticed that channels with `lnd` counterparties do not
receive messages we expect to in a timely manner (or at all) after
sending them a `ChannelReestablish` upon reconnection, or a
`CommitmentSigned` message. This can block the channel state machine
from making progress, eventually leading to force closes, if any pending
HTLCs are committed and their expiration is met.

It seems common wisdom for `lnd` node operators to periodically restart
their node/reconnect to their peers, allowing them to start from a fresh
state such that the message we expect to receive hopefully gets sent. We
can achieve the same end result by disconnecting peers ourselves
(regardless of whether they're a `lnd` node), which we opt to implement
here by awaiting their response within two timer ticks.

Add new DisconnectPeerWithWarning variant to ErrorAction

Remove unreachable warning message send on UnknownRequiredFeature read

`enqueue_message` simply adds the message to the outbound queue, it
still needs to be written to the socket with `do_attempt_write_data`.
However, since we immediately return an error causing the socket to be
closed, the message never actually gets sent.

Implement enqueue_message trait requirements on Message enum

The inner structs of each enum variant already implemented them and we
plan to pass in `Message`s to `enqueue_message` in a future commit.

Merge pull request #2316 from benthecarman/payment-err-dervies

Derive a PartialEq and Eq for PaymentError

Derive a PartialEq and Eq for PaymentError

This lets users compare error types more easily without needing a match
statement.

Merge pull request #2280 from TheBlueMatt/2023-05-event-deadlock

Never block a thread on the `PeerManager` event handling lock

Never block a thread on the `PeerManager` event handling lock

If thre's a thread currently handling `PeerManager` events, the
next thread which attempts to handle events will block on the first
and then handle events after the first completes. (later threads
will return immediately to avoid blocking more than one thread).

This works fine as long as the user has a spare thread to leave
blocked, but if they don't (e.g. are running with a single-threaded
tokio runtime) this can lead to a full deadlock.

Instead, here, we never block waiting on another event processing
thread, returning immediately after signaling that the first thread
should start over once its complete to ensure all events are
handled.

While this could lead to starvation as we cause one thread to go
around and around and around again, the risk of that should be
relatively low as event handling should be pretty quick, and it's
certainly better than deadlocking.

Fixes https://github.com/lightningdevkit/rapid-gossip-sync-server/issues/32

Atomic lock simplification suggestion from @andrei-21

Merge pull request #2284 from dunxen/2023-05-netgraphpartialeqtotallock

Use a total lockorder for `NetworkGraph`'s `PartialEq` impl

Use a total lockorder for `NetworkGraph`'s `PartialEq` impl

`NetworkGraph`'s `PartialEq` impl before this commit was deadlock-prone.
Similarly to `ChannelMonitor`'s, `PartialEq` impl, we use position in
memory for a total lockorder. This uses the assumption that the objects
cannot move within memory while the inner locks are held.

Consider HTLC in-flight count limits when assembling a route

When calculating the amount available to send for the next HTLC, if
we over-count we may create routes which are not actually usable.

Historically this has been an issue, which we resolve over a few
commits.

Here we consider the number of in-flight HTLCs which we are allowed
to push towards a counterparty at once, setting the available
balance to zero if we cannot push any further HTLCs.

We also add some testing when sending to ensure that send failures
are accounted for in our balance calculations.

Consider commitment tx fee while assembling a route

When calculating the amount available to send for the next HTLC, if
we over-count we may create routes which are not actually usable.

Historically this has been an issue, which we resolve over a few
commits.

Here we include the cost of the commitment transaction fee in our
calculation, subtracting the commitment tx fee cost from the
available as we do in `send_payment`.

We also add some testing when sending to ensure that send failures
are accounted for in our balance calculations.

This commit is based on original work by
Gleb Naumenko <naumenko.gs@gmail.com> and modified by
Matt Corallo <git@bluematt.me>.

Simplify test_fail_holding_cell_htlc_upon_free_multihop somewhat

In the coming commits we redo our next-HTLC-available logic which
requires some minor test changes for tests which relied on
calculating routes which were not usable.

Here we do a minor prefactor to simplify a test which now no longer
requires later changes.

Disallow sending an HTLC when the balance needed is pending removal

While its nice to be able to push an HTLC which spends balance that
is removed in our local commitment transaction but awaiting an RAA
from our peer for final removal its by no means a critical feature.

Because peers should really be sending RAAs quickly after we send
a commitment, this should be an exceedingly rare case, and we
already don't expose this as available balance when routing, so
this isn't even made available when sending, only forwarding.

Note that `test_pending_claimed_htlc_no_balance_underflow` is
removed as it tested a case which was only possible because of this
and now is no longer possible.

Merge pull request #2272 from benthecarman/package-broadcast

Support broadcasting multiple transactions at once

Merge pull request #2235 from TheBlueMatt/2023-04-criterion

Replace std's unmaintained bench with criterion

Merge pull request #2226 from alecchendev/2023-04-persist-network-graph-on-rgs

Update BP `NetworkGraph` and `Scorer` persist frequency

Merge pull request #2204 from jkczyz/2023-04-custom-feature-bits

Support for custom feature bits

Merge pull request #1841 from ariard/2022-11-revoked-balance-non-aggregable

Post-anchor: do not aggregate claim of revoked output

Rename EffectiveCapacity::MaximumHTLC to ::AdvertisedMaxHTLC

Also get rid of some trailing whitespace because my text editor likes to do
that.

We'll next add a new variant for max_htlc provided in route hints, which will
be treated differently in scoring.

Remove aggregable flag from PackageTemplate constructor

Anchor: do not aggregate claim of revoked output

See https://github.com/lightning/bolts/pull/803

This protect the justice claim of counterparty revoked output. As
otherwise if the all the revoked outputs claims are batched in a
single transaction, low-feerate HTLCs transactions can delay our
honest justice claim transaction until BREAKDOWN_TIMEOUT expires.

Persist scorer upon update based on event handling

Now that we persist the scorer upon events, we extend timer persistence
from 30 seconds to 1 hour, similar to network graph persistence.

Prune and persist RGS network graph after initial sync

Previously we would wait 60 seconds after startup, however for RGS we
prune/persist after its initial sync since 60 seconds is likely too
long.

Merge pull request #2288 from wpaulino/rust-bitcoin-30-prereqs

Support broadcasting multiple transactions at once

Merge pull request #2271 from tnull/2023-04-fix-onion-panic

Return error when failing onion packet construction

Merge pull request #2286 from benthecarman/spendable-outputs-psbt

Create and Sign PSBTs for spendable outputs

Return error when failing to construc onion messages

Previously, we would panic when failing to construct onion messages in
certain circumstances. Here we opt to always rather error out and don't
panic if something goes wrong during OM packet construction.

Update .gitignore to ignore benchmark data files

Add trivial README to bench to describe how to run them.

Replace std's unmaintained bench with criterion

Rather than using the std benchmark framework (which isn't
maintained and is unlikely to get any further maintenance), we swap
for criterion, which at least gets us a variable number of test
runs so our benchmarks don't take forever.

We also fix the RGS benchmark to pass now that the file in use is
stale compared to today's date.

Add an additional test/bench for routing larger amounts, score more

When benchmarking our router, we previously only ever tested with
amounts under 1,000 sats, which is an incredibly small amount.
While this ensures we have the maximal number of available channels
to consider, it prevents our scorer from getting exercise across
its range. Further, we only score the immediate path we are
expecting to to send over, and not randomly but rather based on the
amount sent.

Here we try to make the benchmarks a bit more realistic by adding
a new benchmark which attempts to send around 100K sats, which is
a reasonable amount to send over a channel today. We also convert
the scoring data to be randomized based on the seed as well as
attempt to (possibly) find a new route for a much larger value and
score based on that. This potentially allows us to score multiple
potential paths between the source and destination as the large
route-find may return an MPP result.

Unify route benchmarking with route tests

There's a few route tests which do the same thing as the benchmarks
as they're also a good test. However, they didn't share code, which
is somewhat wasteful, so we fix that here.

Merge pull request #2237 from henghonglee/issue-2189-score-params

[#2189] Score Fee Params as a passed in parameter

Create and Sign PSBTs for spendable outputs

Move functions around to colocate impl of FeeParams and DecayParams

Score's FeeParams as passed-in params on Routefinding functions

This PR aims to create a "stateless" scorer. Instead of passing
in fee params at construction-time, we want to parametrize the
scorer with an associated "parameter" type, which is then
passed to the router function itself, and allows passing
different parameters per route-finding call.

Update missed comment in Features test

Add Features::set_{required|optional}_custom_bit

Custom message handlers may need to set feature bits that are unknown to
LDK. Provide Features::set_required_custom_bit and
Features::set_optional_custom_bit to allow for this.

Check unknown features compared to handlers

Each message handler provides which features it supports. A custom
message handler may support unknown features. Therefore, these features
should be checked against instead of the features known by LDK.
Additionally, fail the connection if the peer requires features unknown
to the handler. The peer should already fail the connection in the
latter case.

Fix test_restored_packages_retry serialized monitor payload

The purpose of this payload is to ensure we retry restored packages on a
`ChannelMonitor` that has upgraded from a version that previously did
not have such retry logic. We can verify this works by checking whether
a restored package has a `height_timer` of `None` upon deserializing the
monitor payload.

In the previous commit, we added a helper that constructs blocks
whenever tests demand blocks be connected. This helper moved towards
having all connected blocks have a version of 0x2000_0000 (also known as
NO_SOFT_FORK_SIGNALLING). However, previously, it was possible for some
blocks to be connected with a slighty different version: 0x0200_0000,
resulting in different block hashes.

This block hash divergence prompted a failure in this test when
`ConnectStyle::HighlyRedundantTransactionsFirstSkippingBlocks` is used
for `nodes[0]`, since this block connection style reconfirms
transactions redundantly and the serialized monitor payload kept a
reference to the hash of the block with version 0x0200_0000, when it
should be expecting one with version 0x2000_0000.

Use helper to create dummy blocks

`rust-bitcoin v0.30.0` introduces concrete variants for data members of
block `Header`s. To avoid having to update these across every use, we
introduce new helpers to create dummy blocks and headers, such that the
update process is a bit more straight-forward.

Check difficulty transition against `Target` instead of `Work`

`rust-bitcoin v0.30.0` made some changes in this area that no longer
allow us to work with the previously exposed `U256` type. While `Work`
and `Target` (they're inverses of each other) essentially represent the
same concept, it makes more sense from their API's perspective to only
expose difficulty transitions and adjustments on `Target`s.

Ignore lightning-transaction-sync build output