Fix `Route` serialization round-trip

When the `max_total_routing_fee_msat` parameter was added to
`RouteParameters`, the serialization used `map` to get the max fee,
accidentally writing an `Option<Option<u64>>`, but then read it as
an `Option<u64>`. Thus, any `Route`s with a `route_params` written
will fail to be read back.

Luckily, this is an incredibly rarely-used bit of code, so only one
user managed to hit it.

Fix blinded path serialization in `Route`

`Route`'s blinded_path serialization logic writes a blinded path
`Option` per path hop, however on read we (correctly) only read one
blinded path `Option` per path. This causes serialization of
`Route`s with blinded paths to fail to round-trip.

Here we fix this by writing blinded paths per path.

Merge pull request #2644 from TheBlueMatt/2023-09-0.0.117-java-bindings

0.0.117 Bindings Changes

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 #2620 from TheBlueMatt/2023-09-cut-0.0.117

Cut 0.0.117

Bump crate versions to 0.0.117/invoice 0.25

Add 0.0.117 release notes

Merge pull request #2631 from TheBlueMatt/2023-09-pm-no-refs-reqd

Fix `Simple*PeerManager` to not require refs to the `UtxoLookup`

Merge pull request #2634 from TheBlueMatt/2023-09-claimable-unwrap

Avoid unwrap'ing `channel_parameters` in to_counterparty signing

Clean up at least some lifetimes on `SimpleRefPeerManager`

Rather than simply a, b, c, d...we at least use names for a few
things, also splitting the reused 'f lifetime.

Note when we're allowed to unwrap channel parameters in docs

This further documents the parameter-fetching utilities in
`InMemorySigner` to hopefully make them more robust against future
spurious `unwrap`s.

Make `InMemorySigner` parameter-fetching utilities return `Option`s

In the previous commit we fixed a bug where we were spuriously
(indirectly) `unwrap`ing the `channel_parameters` in
`InMemorySigner`. Here we make such bugs much less likely in the
future by having the utilities which do the `unwrap`ing internally
return `Option`s instead.

This makes the `unwrap`s clear at the callsite.

Merge pull request #2595 from TheBlueMatt/2023-09-117-bindings-part1

Various cleanups to make bindings generation simpler

Merge pull request #2632 from TheBlueMatt/2023-09-writeable-rwlock

Implement Readable/Writeable for RwLock wrappers

Merge pull request #2633 from TheBlueMatt/2023-09-expose-onion-parse

Expose `parse_onion_address` publicly in `no-std`

Avoid unwrap'ing `channel_parameters` in to_counterparty signing

Previously, `StaticPaymentOutputDescriptor`s did not include
`channel_parameters` for the signer. As a result, when going to
spend old `StaticPaymentOutputDescriptor`s,
`InMemorySigner::sign_counterparty_payment_input` may be called
with `channel_parameters` set to `None`. This should be fine, but
in fa2a2efef47b5da48ac7a239f3d8a835a7f28164 we started relying on
it (indirectly via `channel_features`) for signing. This caused an
`unwrap` when spending old output descriptors.

This is fixed here by simply avoiding the unwrap and assuming old
`StaticPaymentOutputDescriptor`s represent non-anchor channels.

Remove unused `mem::drop` which drops a reference

Fix new unused variable warning in `test_utils.rs`

Use `crate::prelude::*` to load `Vec`, rather than `crate::Vec`

This is kinda dumb, but the bindings get confused when referring
to `Vec` absolutely in a `use` statement, and there's no reason not
to load our prelude everywhere.

Drop various bounds on types passed to `MonitorUpdatingPersister`

The new `MonitorUpdatingPersister` has a few redundant type bounds
(re-specified on functions after having been specified on the
struct itself), which we remove here.

Further, it requires a `Deref<FeeEstimator>` which is `Clone`able.
This is generally fine in rust, but annoying in bindings, so we
simply elide it in favor if a `&Deref<FeeEstimator>`.

Make `create_onion_message` a freestanding function

The new `create_onion_message` function in `OnionMessenger` is hard
to handle - it has various generic requirements indirectly via the
struct, but they're not bounded by any of the method parameters.
Thus, you can't simply call `OnionMessenger::create_onion_message`,
as various bounds are not specified.

Instead, we move it to a freestanding function so that it can be
called directly without explicitly setting bounds.

Mark `AChannelManager` no-export

The trait itself has no purpose for bindings, as all structs are
concretized anyway. Further, the bindings have specific handling
for generic bounding traits like this.

Mark `SpendableOutputDescriptor::to_psbt_input` as no-export

Its honestly likely not all that useful as its not materially
interoperable with other PSBT libraries. Instead, users should
simply fetch the full PSBT and use the inputs from it as they see
fit.

Drop unnecessary crate:: prefix when accessing `bitcoin` in macro

Unexported macros don't need to use the `$crate` prefix.

Avoid ref to a `Vec` when accessing custom onion TLVs

The bindings can't easily return a reference to a `Vec`, so we
instead split the implementation into vec/slice depending on the
`c_bindings` flag.

Avoid blanket impls in bindings builds

The C bindings implements `Deref` for all traits, so having a
blanket `Deref` implementation ends up conflicting with this.

Simplify score bounding with a unified type

In a few places we require a unified scorer, which implements both
`ScoreLookUp` and `ScoreUpdate`. Rather than double-bounding (which
the bindings generator can't handle directly), we use a top-level
`Score` trait which requires both and is implemented for all
implementers of both supertraits.

Remove unnecessary bounds in scoring

In our scoring logic we have a handful of unnecessary bounds,
leading to extra diff in the bindings branch when those bounds have
to be removed as well as a few cases where bindings generation
simply gets confused.

Here we remove a number of bounds across the scoring traits and
impls, cleaning things up and simplifying bindings changes.

Use `Default::default()` to construct `()` as score-updating param

In 6b0d94a3029f74de3a7542cbba0d48c2f7e5866b we switched most tests
to `Default::default()` for scoring parameters passed to
route-fetching. Here we do the same for the scoring parameters when
passed to score-updating.

Expose `parse_onion_address` publicly in `no-std`

The reason for having a separate `parse_onion_address` from
`FromStr` is to have an onion parsing function in `no-std`, but
when we added it we forgot to make it public. We do this here, as
well as fix a few compilation warnings in `no-std`.

Switch `Simple*ChannelManager` locks around `Score` to `RwLock`

This switches the locks used around `ProbabilisticScorer` in
`Simple*ChannelManager` type aliases to `RwLock`.

Fix `Simple*PeerManager` to not require refs to the `UtxoLookup`

`UtxoLookup` doesn't strictly need to be referenced from the
`PeerManager`, and in fact the new `GossipVerifier` in
`lightning-block-sync` requires itself to be owned by the
`PeerManager` (for circular type reasons).

This allows us to use `lightning-block-sync`'s `GossipVerifier`
with `SimpleArcPeerManager` in ldk-sample.

Implement `Readable`/`Writeable` for `RwLock` wrappers

We now support separate R/W locks in `LockableScore`, which allow
us to do routefinding in parallel, however in order to support
`WriteableScore` for such users we need to implement `Writeable`
for `RwLock` wrappers around `Writeable` types, which we do here.

Merge pull request #2630 from TheBlueMatt/2023-09-117-rc1

Bump crate versions to 0.0.117-rc1/invoice 0.25-rc1

Merge pull request #2610 from wpaulino/missing-htlc-claim-balance

Fix matching of second-stage HTLC claim in get_htlc_balance

Merge pull request #2621 from G8XSU/dont-persist-erroneous-update

Persist entire monitor if there is an error while applying monitor_update

Bump crate versions to 0.0.117-rc1/invoice 0.25-rc1

Fix wrong node broadcaster in test_yield_anchors_events

Add anchors coverage to test_revoked_counterparty_aggregated_claims

Add anchors coverage to test_revoked_counterparty_htlc_tx_balances

Add update_persisted_channel doc to indicate rare case for None update

Persist full monitor if there is an error while applying monitor_update

Motivation: When there is an error while applying monitor_update to a
channel_monitor,  we don't want to persist a 'monitor_update' which
results in a failure to apply later while reading 'channel_monitor' with
updates from storage. Instead, we should persist the entire 'channel_monitor'
here.

Correctly mark chain_sync updates in test_utils

We were incorrectly marking updates as chain_sync
or not in test_utils based on whether monitor_update
is None or not. Instead, use UpdateOrigin to determine it.

Add anchors coverage to test_revoked_counterparty_commitment_balances

Add anchors coverage to test_balances_on_local_commitment_htlcs

Add anchors coverage to test_claim_value_force_close

Add anchors coverage to chanmon_claim_value_coop_close

Add test util to handle bump HTLC events

Fix matching of second-stage HTLC claim in get_htlc_balance

We incorrectly assumed that the descriptor's output index from
second-stage HTLC transaction would always match the HTLC's output index
in the commitment transaction. This doesn't make any sense though, we
need to make sure we map the descriptor to it's corresponding HTLC in
the commitment. Instead, we check that the transaction from which the
descriptor originated from spends the HTLC in question.

Note that pre-anchors, second-stage HTLC transactions are always 1
input-1 output, so previously we would only match if the HTLC was the
first output in the commitment transaction. Post-anchors, they are
malleable, so  we can aggregate multiple HTLC claims into a single
transaction making this even more likely to happen. Unfortunately, we
lacked proper coverage in this area so the bug went unnoticed. To
address this, we aim to extend our existing coverage of
`get_claimable_balances` to anchor outputs channels in the following
commits.

Merge pull request #2629 from jkczyz/2023-09-invreqfailed

Config-guard `Event::InvoiceRequestFailed`

Merge pull request #2605 from wpaulino/anchors-monitor-track-to-remote-script

Use correct to_remote script in counterparty commitments

Remove unused imports

Fix build warning for unused method

Remove an unnecessary enumerate

Config-guard Event::InvoiceRequestFailed

The event cannot be generated publicly, so remove it for now to avoid
users needing to handle it.

Merge pull request #2628 from wvanlint/fix_multiple_shutdown_results

Fix handling multiple ShutdownResults

Expose witness_script for StaticPaymentOutputDescriptor

Fix incorrect anchors `counterparty_payment_script` upon deserialization

Merge pull request #2622 from wpaulino/funding-and-commitment-tx-confirm-same-block

Avoid early return upon confirmation of channel funding

Merge pull request #2626 from TheBlueMatt/2023-09-revert-2476

Revert "Remove AvailableBalances::balance_msat"

Fix off-by-one max witness estimate for P2WPKH StaticPaymentDescriptor

We were not accounting for the extra byte denoting the number of items
in the witness stack.

Support signing to_remote anchors variant for StaticPaymentOutput

`to_remote` outputs on commitment transactions with anchor outputs have
an additional `1 CSV` constraint on its spending condition,
transitioning away from the previous P2WPKH script to a P2WSH.

Since our `ChannelMonitor` was never updated to track the proper
`to_remote` script on anchor outputs channels, we also missed updating
our signer to handle the new script changes.

Use correct to_remote script in counterparty commitments

While our commitment transactions did use the correct `to_remote`
script, the `ChannelMonitor`'s was not as it is tracked separately. This
would lead to users never receiving an `Event::SpendableOutputs` with a
`StaticPaymentOutput` descriptor to claim the funds.

Luckily, any users affected which had channel closures confirmed by a
counterparty commitment just need to replay the closing transaction to
receive the event.

Merge pull request #2624 from wpaulino/2609-follow-up

Address 2609 follow-up comments

Fix handling multiple ShutdownResults

Merge pull request #2623 from wpaulino/htlc-claim-receive-preimage-after-close

Claim HTLCs with preimage from currently confirmed commitment

Avoid early return upon confirmation of channel funding

This early return is only possible if the channel requires a single
confirmation, allowing a `channel_ready` message to go out. This can be
problematic though if a commitment transaction (specifically from the
counterparty, as the channel would be immediately closed if a local
commitment is broadcast) also confirms within the same block. The
`ChannelMonitor` will detect both, but it won't inform the
`ChannelManager` at all. Luckily, while the channel still is considered
open to the `ChannelManager`, the `ChannelMonitor` will reject any
further updates to the channel state.

Revert "Remove AvailableBalances::balance_msat"

While removing the `balance_msat` field absolutely makes sense -
it is, at best, confusing - we really need a solid replacement for
it before we can do so. While one such replacement is in progress,
it is not complete and we'd like to not block our current release
on its completion.

This reverts commit ef5be580f51d6756612fea710516c0297203f4dc.

Only yield DelayedPaymentOutput descriptors once their delay expires

Otherwise, we could give users a descriptor ahead of time that will
result in an invalid transaction spend/broadcast.

Merge pull request #2617 from wpaulino/no-persist-same-channel-update

Avoid persisting on same counterparty's ChannelUpdate

Merge pull request #2591 from TheBlueMatt/2023-09-2562-followups

Doc and comment followups to #2562

Note required levels of descendant transactions in get_spendable_outputs

Three levels of descendant transactions starting from the channel's
funding transaction should cover all potential spendable outputs.

The first level covers the commitment transaction.

The second level covers the to_self claims, to_remote claims,
second-stage HTLC claims and justice transactions.

The third levels covers the justice transactions on second-stage HTLCs,
and to_self claims on second-stage HTLCs.

Test preimage claim after reorg of counterparty commitment

This test adds coverage for receiving a preimage after seeing a
counterparty commitment confirm, followed by a reorg and the
confirmation of a different commitment instead.

The first test covers the case where a holder commitment confirms after
the counterparty commitment reorg.

The second test covers the case where a previous counterparty commitment
confirms after the latest counterparty commitment reorg.

Claim HTLCs with preimage from currently confirmed commitment

We should always claim HTLCs from the currently confirmed commitment,
rather than always claiming from the latest or previous counterparty
commitment if we've seen either confirm onchain at a prior point.

Avoid persisting on same counterparty's ChannelUpdate

Some nodes may rebroadcast their `ChannelUpdate` to their counterparty
on every connection establishment, which leads to us doing an additional
persist most of the time when nothing has changed. Now, we'll only
persist if we receive an update that changes anything.

Merge pull request #2609 from wpaulino/monitor-get-spendable-output

Allow retrieval of SpendableOutputDescriptors from relevant transactions

Merge pull request #2604 from TheBlueMatt/2023-09-route-overpay-limit

Try to overpay the recipient if we fail to find a path at all and limit overpay

Retrieve all possible spendable outputs from transactions

Assuming our keys haven't been compromised, and that random transactions
aren't learning of these scripts somehow and sending funds to them, it
was only possible for one spendable output to exist within a
transaction.

- `shutdown_script` can only exist in co-op close transactions.
- `counterparty_payment_script` can only exist in counterparty
  commitment transactions.
- `broadcasted_holder_revokable_script` can only exist in holder
  commitment/HTLC transactions.
- `destination_script` can exist in any other type of claim we support.

Now that we're exposing this API to users such that they can rescan any
relevant transactions, there's no harm in allowing them to claim more
funds from spendable outputs than we expected.

Allow retrieval of SpendableOutputDescriptors from relevant transactions

Currently, our API will only expose `SpendableOutputDescriptor`s once
after they are no longer under reorg risk (see `ANTI_REORG_DELAY`).
Users have often requested they'd like the ability to retrieve these in
some other way, either for historical purposes, or to handle replaying
any in the event of a failure.

Add more details about async persistence completion/backgrounding

This clarifies somewhat that async persistence should run
indefinitely or keep trying via polling, and that either is
acceptable.

Log max routing fee before we start pathfinding

This may be useful in debugging routing failures in the future.

Include any recipient overpayment amounts in the route fee limit

If the user told us to limit their total fee exposure, we should
do so including any potential overpayment to the recipient, which
is ultimately a part of the "fee" as far as the user is concerned.

Try to overpay the recipient if we fail to find a path at all

Previously we'd only try to overpay if we managed to find a path
to the recipient which was sufficient. However, if we fail to find
any path to the recipient at all we should still retry overpaying
the recipient. Ultimately we should be silling to pay whatever
reasonable performance penalty if the alternative is not finding a
path at all, which we do here.

Allow routefinding again due to HTLC limit based on >= not >

While this doesn't matter much in practice, if we go around again
when route-finding to try to meet an htlc_minimum_msat, we use the
`recommended_value_msat` which can work if we meet the
`htlc_minimum_msat` on a channel exactly, so using >= rather than >
can capture cases with 1msat more.

Merge pull request #2612 from TheBlueMatt/2023-09-namespace-split

Refer to top-level persistence namespaces as primary_namespace

Merge pull request #2575 from tnull/2023-09-fix-debug-panic

Various router fixes and #2417 follow-ups

Merge pull request #2611 from TheBlueMatt/2023-09-no-close-on-bad-update

Don't FC when a `channel_update` has a bogus `htlc_minimum_msat`