Always remove disconnected peers with no channels

When a peer disconnects but still has channels, the peer's `peer_state`
entry in the `per_peer_state` is not removed by the `peer_disconnected`
function. If the channels with that peer is later closed while still
being disconnected (i.e. force closed), we therefore need to remove the
peer from `peer_state` separately.

To remove the peers separately, we push such peers to a separate HashSet
that holds peers awaiting removal, and remove the peers on a timer to
limit the negative effects on parallelism as much as possible.

Update `ChannelManager` docs

Updates multiple instances of the `ChannelManager` docs related to the
previous change that moved the storage of the channels to the
`per_peer_state`. This docs update corrects some grammar errors and
incorrect information, as well as clarifies documentation that was
confusing.

Check `peer_state` existence more idiomatically

Remove redundant Vec in `get_and_clear_pending_msg_events`

Don't clone the Vec in `remove_first_msg_event_to_node`

Remove redundant hashmap lookups

Avoid doing the same hashmap lookups twice in a row, when it's not
needed. Refactor `claim_funds_from_hop` in order to enable this change.

Don't pass `per_peer_state` to `claim_funds_from_hop`

Track if a peer is connected or not in `ChannelManager`

Merge pull request #1873 from jurvis/jurvis/2022-11-expose-pending-payments

Expose pending payments through `ChannelManager`

Merge pull request #2002 from valentinewallace/2023-01-keysend-retries

Support auto-retrying keysend payments in `ChannelManager`

Merge pull request #1996 from valentinewallace/2023-01-migrate-payment-scoring

Score payment paths from events in `BackgroundProcessor`

Expose pending payments through ChannelManager

Adds a new method, `list_recent_payments ` to `ChannelManager` that
returns an array of `RecentPaymentDetails` containing the payment
status (Fulfilled/Retryable/Abandoned) and its total amount across all
paths.

Score payment paths in BackgroundProcessor

Use TestScorer in BackgroundProcessor testing

Spontaneous payments: make preimage construction more concise

Support spontaneous payment retries in ChannelManager

Store keysend preimage in outbound payments

This sets us up for spontaneous payment retries in ChannelManager.

Currently, retrying spontaneous payments is broken in InvoicePayer because it
does not include the keysend preimage on retry.

Merge pull request #1994 from TheBlueMatt/2023-01-1916-followups

1916 Followups Part 1

Reduce the code in the commitment_signed_dance macro

This should marginally reduce compile times for the tests by
reducing the total volume of code across the tests in the lightning
crate.

Use only the failed amount when retrying payments, not the full amt

When we landed the initial in-`ChannelManager` payment retries, we
stored the `RouteParameters` in the payment info, and then re-use
it as-is for new payments. `RouteParameters` is intended to store
the information specific to the *route*, `PaymentParameters` exists
to store information specific to a payment.

Worse, because we don't recalculate the amount stored in the
`RouteParameters` before fetching a new route with it, we end up
attempting to retry the full payment amount, rather than only the
failed part.

This issue brought to you by having redundant data in
datastructures, part 5,001.

Move retry-limiting to `retry_payment_with_route`

The documentation for `Retry` is very clear that it counts the
number of failed paths, not discrete retries. When we added
retries internally in `ChannelManager`, we switched to counting
the number if discrete retries, even if multiple paths failed and
were replace with multiple MPP HTLCs.

Because we are now rewriting retries, we take this opportunity to
reduce the places where retries are analyzed, specifically a good
chunk of code is removed from `pay_internal`.

Because we now retry multiple failed paths with one single retry,
we keep the new behavior, updating the docs on `Retry` to describe
the new behavior.

Log more information when retrying a payment attempt fails

Test the `RouteParameters` passed to `TestRouter`

`TestRouter` allows us to simply select the `Route` that will be
returned in the next `find_route` call, but it does so without any
checking of what was *requested* for the call. This makes it a
somewhat dubious test utility as it very helpfully ensures we
ignore errors in the routes we're looking for.

Instead, we require users of `TestRouter` pass a `RouteParameters`
to `expect_find_route`, which we compare against the requested
parameters passed to `find_route`.

Use the `PaymentParameter` final CLTV delta over `RouteParameters`

`PaymentParams` is all about the parameters for a payment, i.e. the
parameters which are static across all the paths of a paymet.
`RouteParameters` is about the information specific to a given
`Route` (i.e. a set of paths, among multiple potential sets of
paths for a payment). The CLTV delta thus doesn't belong in
`RouterParameters` but instead in `PaymentParameters`.

Worse, because `RouteParameters` is built from the information in
the last hops of a `Route`, when we deliberately inflate the CLTV
delta in path-finding, retries of the payment will have the final
CLTV delta double-inflated as it inflates starting from the final
CLTV delta used in the last attempt.

When we calculate the `final_cltv_expiry_delta` to put in the
`RouteParameters` returned via events after a payment failure, we
should re-use the new one in the `PaymentParameters`, rather than
the one that was in the route itself.

Merge pull request #1976 from tnull/2023-01-expose-impl-writeable-msg

Expose `impl_writeable_msg`

Move the final CLTV delta to `PaymentParameters` from `RouteParams`

`PaymentParams` is all about the parameters for a payment, i.e. the
parameters which are static across all the paths of a paymet.
`RouteParameters` is about the information specific to a given
`Route` (i.e. a set of paths, among multiple potential sets of
paths for a payment). The CLTV delta thus doesn't belong in
`RouterParameters` but instead in `PaymentParameters`.

Worse, because `RouteParameters` is built from the information in
the last hops of a `Route`, when we deliberately inflate the CLTV
delta in path-finding, retries of the payment will have the final
CLTV delta double-inflated as it inflates starting from the final
CLTV delta used in the last attempt.

By moving the CLTV delta to `PaymentParameters` we avoid this
issue, leaving only the sought amount in the `RouteParameters`.

Merge pull request #1998 from tnull/2023-01-no-none-in-channel-relevant-txids

Only return previously confirmed Txids from CM's `get_relevant_txids()`

Add version note in `Confirm` docs

While now `ChannelManager` will only return previously confirmed
transactions, we can't ensure the same for `ChainMonitor`, as we need to
maintain backwards compatibility with version prior to 0.0.113, at which
we started tracking the block hash in `ChannelMonitor`s. We therefore
add a note to the docs stating that users need to track confirmations on
their own for channels created prior to 0.0.113.

Return only `Some(block_hash)` in CM rel. txids

As of now the `Confirm::get_relevant_txids()` docs state that it won't
return any transactions for which we hadn't previously seen a
confirmation. To align its functionality a bit more with the docs, at
least for `ChannelManager`, we only return values for which we had
registered a confirmation block hash before.

Expose Retry enum from channelmanager module

Merge pull request #1997 from Kurtsley/fix-clean-up-documentation

Clean up documentation in the create_phantom_invoice functions

Clean up documentation in the create_phantom_invoice functions

Merge pull request #1961 from TheBlueMatt/2023-01-expose-hist-buckets

Expose historical bucket data via new accessors

Merge pull request #1972 from jkczyz/2023-01-bolt12-spec-updates

BOLT 12 spec updates

Expose historical bucket data via new accessors

Users should be able to view the data we use to score channels, so
this exposes that data in new accessors.

Fixes #1854.

Calc decayed buckets to decide if we have valid historical points

When we're calculating if, once we apply the unupdated decays, the
historical data tracker has enough data to assign a score, we
previously calculated the decayed points while walking the buckets
as we don't use the decayed buckets anyway (to avoid losing
precision). That is fine, except that as written it decayed
individual buckets additional times.

Instead, here we actually calculate the full set of decayed buckets
and use those to decide if we have valid points. This adds some
additional stack space and may in fact be slower, but will be
useful in the next commit and shouldn't be a huge change.

Update docs regarding payment path privacy

Disallow offer_metadata in Refund

The offer_metadata was optional but is redundant with invreq_metadata
(i.e., payer_metadata) for refunds. It is now disallowed in the spec and
was already unsupported by RefundBuilder.

Allow quantity in Refund

The spec always allowed this but the reason was unclear. It's useful if
the refund is for an invoice paid for offer where a quantity was given
in the request. The description in the refund would be from the offer,
which may have given a unit for each item. So allowing a quantity makes
it clear how many items the refund is for.

Support explicit quantity_max = 1 in Offer

The spec was modified to allow setting offer_quantity_max explicitly to
one. This is to support a use case where more than one item is supported
but only one item is left in the inventory. Introduce a Quantity::One
variant to replace Quantity::Bounded(1) so the later can be used for the
explicit setting.

Merge pull request #1985 from Kurtsley/chore-no-std-phantom-invoice

Remove std::SystemTime from create_phantom_invoice, ref #1978

Remove std::SystemTime from create_phantom_invoice, ref #1978

Replace current_timestamp call with no-std duration_from_epoch

Merge pull request #1974 from danielgranhao/speed-up-secure-random-byte-gen

Use `Chacha20` in `get_secure_random_bytes()`

Merge pull request #1991 from TheBlueMatt/2023-01-fix-comment

Remove stale comment in test

Merge pull request #1986 from TheBlueMatt/2023-01-monitor-eq

Implement PartialEq for ChannelMonitor

Remove stale comment in test

This should have been done in 7dcbf2cd1c4de29b7c32165ca3d6ac3c47f1
but was not.

Add `get_secure_random_bytes()` benchmark

Merge pull request #1984 from TheBlueMatt/2023-01-test-robust

Make `test_duplicate_payment_hash_one_failure_one_success` robust

Remove the `ChannelMonitor` secp context

`ChannelMonitor` indirectly already has a context - the
`OnchainTxHandler` has one. This makes it trivial to remove the
existing one, so we do so for a free memory usage reduction.

Implement `PartialEq` for `ChannelMonitor`

It turns out `#[derive(PartialEq)]` will automatically bound the
`PartialEq` implementation by any bounds on the struct also being
`PartialEq`. This means to use an auto-derived `ChannelMonitor`
`PartialEq` the `EcdsaSigner` used must also be `PartialEq`, but
for the use-cases we have today for a `ChannelMonitor` `PartialEq`
it doesn't really matter - we use it internally in tests and
downstream users wanted similar test-only usage.

Fixes #1912.

Merge pull request #1916 from valentinewallace/2022-11-chanman-payment-retries

`ChannelManager` Payment Retries

Make `test_duplicate_payment_hash_one_failure_one_success` robust

`test_duplicate_payment_hash_one_failure_one_success` currently
fails if the "wrong" HTLC is picked to be claimed. Given the HTLCs
are identical, there's no way to figure out which we should claim.
The test instead relies on a magic value - the first one is the
right one....unless we change our CSPRNG implementation. When we
try to do so, the test randomly fails.

Here we change one HTLC to a lower amount so we can figure out
which transaction to broadcast to make the test robust against
CSPRNG changes.

Implement `PartialEq`/`Eq` for `Event`s

Merge pull request #1948 from alecchendev/custom-fail-back-err

Allow specifying an error when failing back HTLC

Merge pull request #1799 from TheBlueMatt/2022-10-heap-nerdsnipe

Router Optimizations

Add test_fail_htlc_backwards_with_reason

Add a test for newly added function failing back a basic payment
and ensuring the intended failure code and data are sent back
to the peer.

Add FailureCode enum and ChannelManager::fail_htlc_backwards_with_reason

FailureCode is used to specify which error code and data to send
to peers when failing back an HTLC.

ChannelManager::fail_htlc_backwards_with_reason
allows a user to specify the error code and
corresponding data to send to peers when failing back an HTLC.
This function is mentioned in Event::PaymentClaimable docs.
ChannelManager::get_htlc_fail_reason_from_failure_code was also
added to assist with this function.

Disambiguate send_payment_internal from pay_internal

Payment retries: copy tests from InvoicePayer

As part of migrating payment retries from InvoicePayer to ChannelManager,
several tests don't need a rewrite and can be pretty much copied and pasted.

Test ChannelManager automatic retries

Support sending payments with a retry strategy in ChannelManager

Retry HTLCs in process_pending_htlc_forwards

Remove AllPathsFailed outbounds at send_payment_internal callsites instead

This makes it easier to retry payments if all paths fail on initial send, in
in which case we'll want to hold off on removing the pending payment

Generate PendingHTLCsForwardable upon retryable payment

Decode onion fail outside of outbound_payments lock

It's not ideal to do all this computation while the lock is held. We also want
to decode the failure *before* taking the lock, so we can store the failed scid
in the relevant outbound for retry in the next commit(s).

Store retry data in PendingOutboundPayment::Retryable

Used in upcoming commit(s) to automatically retry HTLCs in ChannelManager

Clean up `compute_fees` and add a saturating variant

Often when we call `compute_fees` we really just want it to
saturate and we deal with `u64::max_value` later. In that case,
we're much better off doing the saturating in the `compute_fees` as
it can use CMOVs rather than branching at each step and then
`unwrap_or`ing at the callsite.

Add a fuzzer to check that `IndexedMap` is equivalent to `BTreeMap`

Swap `IndexedMap` implementation for a `HashMap`+B-Tree

Our network graph has to be iterable in a deterministic order and
with the ability to iterate over a specific range. Thus,
historically, we've used a `BTreeMap` to do the iteration. This is
fine, except our map needs to also provide high performance lookups
in order to make route-finding fast. Sadly, `BTreeMap`s are quite
slow due to the branching penalty.

Here we replace the implementation of our `IndexedMap` with a
`HashMap` to store the elements itself and a `BTreeSet` to store
the keys set in sorted order for iteration.

As of this commit on the same hardware as the above few commits,
the benchmark results are:

```
test routing::router::benches::generate_mpp_routes_with_probabilistic_scorer ... bench: 109,544,993 ns/iter (+/- 27,553,574)
test routing::router::benches::generate_mpp_routes_with_zero_penalty_scorer  ... bench:  81,164,590 ns/iter (+/- 55,422,930)
test routing::router::benches::generate_routes_with_probabilistic_scorer     ... bench:  34,726,569 ns/iter (+/- 9,646,345)
test routing::router::benches::generate_routes_with_zero_penalty_scorer      ... bench:  22,772,355 ns/iter (+/- 9,574,418)
```

Add a new `IndexedMap` type and use it in network graph storage

Our network graph has to be iterable in a deterministic order and
with the ability to iterate over a specific range. Thus,
historically, we've used a `BTreeMap` to do the iteration. This is
fine, except our map needs to also provide high performance lookups
in order to make route-finding fast. Sadly, `BTreeMap`s are quite
slow due to the branching penalty.

Here we replace the `BTreeMap`s in the scorer with a dummy wrapper.
In the next commit the internals thereof will be replaced with a
`HashMap`-based implementation.

Drop A* implementation in the router for simple Dijkstra's

As evidenced by the previous commit, it appears our A* router
does worse than a more naive approach. This isn't super surpsising,
as the A* heuristic calculation requires a map lookup, which is
relatively expensive.

```
test routing::router::benches::generate_mpp_routes_with_probabilistic_scorer ... bench: 169,991,943 ns/iter (+/- 30,838,048)
test routing::router::benches::generate_mpp_routes_with_zero_penalty_scorer  ... bench: 122,144,987 ns/iter (+/- 61,708,911)
test routing::router::benches::generate_routes_with_probabilistic_scorer     ... bench:  48,546,068 ns/iter (+/- 10,379,642)
test routing::router::benches::generate_routes_with_zero_penalty_scorer      ... bench:  32,898,557 ns/iter (+/- 14,157,641)
```

Merge pull request #1983 from valentinewallace/2022-01-update-contributingmd

Merge pull request #1878 from dunxen/2022-11-config-minfinalcltvexpiry

Allow configurable `min_final_cltv_expiry_delta`

contributing.md: fix link and link to CoC

Merge pull request #1967 from arik-so/2023-01-rename-signer-traits

Split out `EcdsaChannelSigner` method from `BaseSign`, and rename it to `ChannelSigner`

Parameterize add_new_pending_payment with retry strategy and route params

Copy Retry from invoice module to outbound_payment module

Also configure it such that in std tests, it will use SinceEpoch instead of
Instant so time can be manually advanced.

Add new payment type and metadata bytes

Adds two new payment `Method`s for identifying payments with custom
`min_final_cltv_expiry_delta` as payments with LDK or user payment
hashes.

The `min_final_cltv_expiry_delta` value is packed into the first 2
bytes of the expiry timestamp in the payment secret metadata.

Add `min_final_cltv_expiry` parameter to invoice utils

All utility functions for invoice construction will now also accept an
Option<>al `min_final_cltv_expiry_delta` which is useful for things like
swaps etc. The `min_final_cltv_expiry_delta` will default back to
`MIN_FINAL_CLTV_EXPIRY_DELTA` if `None` is provided.

Add `_delta` suffix to `min_final_cltv_expiry`

This matches the spec and helps avoid any confusion around
naming. We're also then consistent with `cltv_expiry` in an HTLC being
the actual block height value for the CLTV and not a delta.

Make `Channel` and `ChannelManager` less particular about their `Signer` type.

Rename `Sign` to `WriteableEcdsaChannelSigner`.

Separate channel-type-agnostic methods into `ChannelSigner` trait.

Rename `BaseSign` to `EcdsaChannelSigner`.

`impl Display for NodeId`

`NodeId` is a public key, there's not much reason to not implement
`Display` for it and only `Debug`.

Merge pull request #1926 from jkczyz/2022-12-invoice

BOLT 12 `invoice` encoding and building

Copy PaymentAttempts from invoice module to outbound_payment module

Expose `impl_writeable_msg`

Fix unused_imports warning in no-std tests

Invoice parsing tests

Tests for checking invoice semantics when parsing invoice bytes as
defined by BOLT 12.

Invoice building tests

Tests for checking invoice message semantics when building an invoice as
defined by BOLT 12.

Expand invoice module docs and include an example

Use SystemTime::now() for Invoice creation time

For std builds, Invoice::created_at can be automatically set upon
construction using SystemTime::now() offset by SystemTime::UNIX_EPOCH.
Change InvoiceRequest::respond_with and Refund::respond_with to only
take a created_at parameter in no-std builds.

Builder for creating invoices for refunds

Add a builder for creating invoices for a refund and required fields.
Other settings are optional and duplicative settings will override
previous settings. Building produces a semantically valid `invoice`
message for the refund, which then can be signed with the key associated
with the provided signing pubkey.

Builder for creating invoices for offers

Add a builder for creating invoices for an offer from a given request
and required fields. Other settings are optional and duplicative
settings will override previous settings. Building produces a
semantically valid `invoice` message for the offer, which then can be
signed with the key associated with the offer's signing pubkey.

Invoice encoding and parsing

Define an interface for BOLT 12 `invoice` messages. The underlying
format consists of the original bytes and the parsed contents.

The bytes are later needed for serialization. This is because it must
mirror all the `offer` and `invoice_request` TLV records, including
unknown ones, which aren't represented in the contents.

Invoices may be created for an Offer (from an InvoiceRequest) or for a
Refund. The primary difference is how the signing pubkey is given -- by
the writer of the offer or the reader of the refund.

Update min-inbound-fee values on `NetworkGraph` load

Historically we've had various bugs in keeping the
`lowest_inbound_channel_fees` field in `NodeInfo` up-to-date as we
go. This leaves the A* routing less efficient as it can't prune
hops as aggressively.

In order to get accurate benchmarks, this commit updates the
minimum-inbound-fees field on load. This is not the most efficient
way of doing so, but suffices for fetching benchmarks and will be
removed in the coming commits.

Note that this is *slower* than the non-updating version in the
previous commit. While I haven't dug into this incredibly deeply,
the graph snapshot in use has min-fee info for only 9,618 of
20,818 nodes. Thus, it is my guess that with the graph snapshot
as-is the branch predictor is able to largely remove the A*
heuristic lookups, but with this change it is forced to wait for
A* heuristic map lookups to complete, causing a performance
regression.

```
test routing::router::benches::generate_mpp_routes_with_probabilistic_scorer ... bench: 182,980,059 ns/iter (+/- 32,662,047)
test routing::router::benches::generate_mpp_routes_with_zero_penalty_scorer  ... bench: 151,170,457 ns/iter (+/- 75,351,011)
test routing::router::benches::generate_routes_with_probabilistic_scorer     ... bench:  58,187,277 ns/iter (+/- 11,606,440)
test routing::router::benches::generate_routes_with_zero_penalty_scorer      ... bench:  41,210,193 ns/iter (+/- 18,103,320)
```

Update the lightning graph snapshot used in benchmarks

The previous copy was more than one and a half years old, the
lightning network has changed a lot since!

As of this commit, performance on my Xeon W-10885M with a
SK hynix Gold P31 storing a BTRFS volume is as follows:

```
test ln::channelmanager::bench::bench_sends                                  ... bench:   5,896,492 ns/iter (+/- 512,421)
test routing::gossip::benches::read_network_graph                            ... bench: 1,645,740,604 ns/iter (+/- 47,611,514)
test routing::gossip::benches::write_network_graph                           ... bench: 234,870,775 ns/iter (+/- 8,301,775)
test routing::router::benches::generate_mpp_routes_with_probabilistic_scorer ... bench: 166,155,032 ns/iter (+/- 30,206,162)
test routing::router::benches::generate_mpp_routes_with_zero_penalty_scorer  ... bench: 136,843,661 ns/iter (+/- 67,111,218)
test routing::router::benches::generate_routes_with_probabilistic_scorer     ... bench:  52,954,598 ns/iter (+/- 11,360,547)
test routing::router::benches::generate_routes_with_zero_penalty_scorer      ... bench:  37,598,126 ns/iter (+/- 17,262,519)
test bench::bench_sends                                                      ... bench:  37,760,922 ns/iter (+/- 5,179,123)
test bench::bench_reading_full_graph_from_file                               ... bench:      25,615 ns/iter (+/- 1,149)
```

Merge pull request #1951 from wpaulino/remove-get-node-secret