Move final_cltv_expiry_delta from PaymentParams to Payee::Clear

Since blinded pay params won't have this value.

Add BOLT 12 features to PaymentParams

Move BOLT11 features from top level PaymentParams to Payee::Clear

Since blinded payees don't have this.

Error if BOLT 11 features are provided for blinded payment params

Move payee node id from top level PaymentParams to Payee::Clear

Since blinded payees don't have one

Error if clear hints are provided for blinded PaymentParams

Groundwork for refactoring PaymentParams::Hints to ::Payee

Minor changes in preparation for supporting route blinding in
PaymentParameters. In the next commit, we'll be moving more
unblinded-payee-specific fields from the top level parameters into the clear
enum variant.

Merge pull request #2244 from benthecarman/signature-size

Incorporate low-R values into estimate signature size

Merge pull request #2213 from benthecarman/error-sign-provider-addrs

Allow get_shutdown_scriptpubkey and get_destination_script to return an Error

Allow get_shutdown_scriptpubkey and get_destination_script to return an error

Incorporate low-R values into estimate signature size

Merge pull request #2245 from TheBlueMatt/2023-04-ping-count-overflow

Fix overflow in `awaiting_pong_timer...` with too many peers

Merge pull request #2217 from alecchendev/2023-04-expose-hash-in-balance

Expose `PaymentHash` and `PaymentPreimage` in `Balance`

Merge pull request #2239 from valentinewallace/2023-04-remove-redundant-final-cltv-param

Remove redundant `final_cltv_delta` param from `get_route`

Fix overflow in `awaiting_pong_timer...` with too many peers

If we have more than
127 / `MAX_BUFFER_DRAIN_TICK_INTERVALS_PER_PEER` (31) peers,
`awaiting_pong_timer_tick_intervals` can overflow before we hit
the limit. This isn't super harmful, we'll still disconnect peers
as long as they don't send *any* messages between two pings, but it
does cause us to not disconnect peers which are extremely slow in
responding to messages, e.g. because they are overloaded.

Merge pull request #2230 from freddiekrugerrand/2228-validatechainhash

Check chain hash for channel announcement and update

Merge pull request #2044 from freddiekrugerrand/1782-limitchannelhints

Limit route hints to three channels

Remove redundant final_cltv_delta param from get_route

PaymentParameters already includes this value.

This set us up to better support route blinding, since there is no known
final_cltv_delta when paying to a blinded route.

Merge pull request #2234 from dunxen/2023-04-bpteststemp

Use `env::temp_dir()` for BP tests

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

Trivial Bindings Updates

Merge pull request #2233 from TheBlueMatt/2023-04-fix-future-leak

Fix a leak in FutureState when a Notifier is dropped un-woken

Check chain hash for channel announcement and update

Use `env::temp_dir()` for BP tests

Currently `BackgroundProcessor` tests create persister directories in the
current working directory and rely on cleaning up in a `Drop` implementation.

Unfortunately, it seems that in the async tests that nodes are not
`drop()`ed for some reason and so the directories created by those
tests remain behind in the current working directory.

This commit at least ensures that these test directories are created in
a temporary location for the OS using `temp_dir()`. It doesn't aim to
solve the lack of cleanup in the async tests.

Partial fix for #2224 but I believe it's enough to resolve it as these
temp directories that do remain will be purged by the OS at some stage
and are overwritten by subsequent tests if there is a conflict.

Fix a leak in `FutureState` when a `Notifier` is dropped un-woken

If a `Notifier` has an internal `FutureState` which gathers some
sleeper callbacks, but is never actaully woken, those callbacks
will leak due to a circular `Arc` reference when the `Notifier` is
`drop`'d.

Because `Notifier`s are rarely `drop`'d in production this isn't a
huge deal, but shows up materially in bindings tests as they spawn
many nodes over the course of a short test.

Fixes #2232

Hold a reference to the `Arc<FutureState>` when completing futures

This will allow us to pass in that state to the callbacks in the
next commit.

Add a bindings constructor for `lightning-invoice`'s `Sha256` wrapper

[bindings] Disable BOLT12 builders which require move semantics

Limit phantom invoice hints to 3

Move phantom route hint selection into its own function

Merge pull request #2222 from benthecarman/pub-utxo-resolver

Merge pull request #2211 from TheBlueMatt/2023-04-0.0.115-cut

Cut 0.0.115

Add 0.0.115 CHANGELOG entries

Bump crate versions to 0.0.115/invoice 0.23

Merge pull request #2004 from tnull/2023-02-add-async-bp-example

Add Tokio example to `process_events_async` docs

Merge pull request #2209 from TheBlueMatt/2023-04-better-discon-err-msg

Clarify the error message when we disconnect a peer

Merge pull request #2220 from TheBlueMatt/2023-04-dont-ban-cln

Don't remove nodes if there's no channel_update for a temp failure

Add Tokio example to `process_events_async` docs

Add function for updating network graph with announcement with no UTXO resolver

Don't remove nodes if there's no channel_update for a temp failure

Previously, we were requiring any `UPDATE` onion errors to include
a `channel_update`, as the spec mandates[1]. If we see an onion
error which is missing one we treat it as a misbehaving node that
isn't behaving according to the spec and simply remove the node.

Sadly, it appears at least some versions of CLN are such nodes, and
opt to not include `channel_update` at all if they're returning a
`temporary_channel_failure`. This causes us to completely remove
CLN nodes from our graph after they fail to forward our HTLC.

While CLN is violating the spec here, there's not a lot of reason
to not allow it, so we go ahead and do so here, treating it simply
as any other failure by letting the scorer handle it.

[1] The spec says `Please note that the channel_update field is
mandatory in messages whose failure_code includes the UPDATE flag`
however doesn't repeat it in the requirements section so its not
crazy that someone missed it when implementing.

Remove unused import in functional_test_utils

Fix unused `Secp256k1` context in monitor_tests

Merge pull request #2221 from TheBlueMatt/2023-04-bp-exit-fast

Check for `background-processor` exit condition before+after sleep

Merge pull request #2146 from valentinewallace/2023-03-blinded-pathfinding-groundwork

Blinded pathfinding groundwork

Check for `background-processor` exit condition before+after sleep

In a synchronous `BackgroundProcessor`, the exit is done by setting
an atomic flag, which is most likely to happen while we're asleep.
Thus, we previously checked for the exit condition after the sleep
(and after we persisted the `ChannelManager`, if required, though
this is no longer required and dates back to when we didn't do a
re-persist after breaking out of the main loop).

For an async `background-processor`, this is also fine, however
because of the relatively longer sleep time, if the exit flag is
set via a sleep check returning true during event processing, we
may end up delaying exit rather substantially.

In order to avoid this, we simply check for the exit condition both
before and immediately after the sleep in `background-processor`.

Add payment hash to `MaybePreimageClaimableHTLC`

Add payment hash to `MaybeTimeoutClaimableHTLC`

Add payment preimage and hash to `ContentiousClaimable`

DRY up repeated HTLC `Balance`s in tests

This makes it easier to add a new field on the `Balance` variants.

Add `PartialOrd`, `Ord` to `PaymentHash`, `PaymentPreimage` for tests

Merge pull request #2212 from wpaulino/off-by-one-locktime

Fix off-by-one finalized transaction locktime

Fix off-by-one finalized transaction locktime

While these transactions were still valid, we incorrectly assumed that
they would propagate with a locktime of `current_height + 1`, when in
reality, only those with a locktime strictly lower than the next height
in the chain are allowed to enter the mempool.

Catch up test nodes to latest block height

In a future commit, we plan to correctly enforce that the spending
transaction has a valid locktime relative to the chain for the node
broascasting it in `TestBroadcaster::broadcast_transaction` to. We catch
up these test node instances to their expected height, such that we do
not fail said enforcement.

Use current height when generating claims on block_disconnected

The `height` argument passed to `OnchainTxHandler::block_disconnected`
represents the height being disconnected, and not the current height.
Due to the incorrect assumption, we'd generate a claim with a locktime
in the future.

Ultimately, we shouldn't be generating claims within
`block_disconnected`. Rather, we should retry the claim at a later block
height, since the bitcoin blockchain does not ever roll back without
connecting a new block. Addressing this is left for future work.

Merge pull request #2199 from tnull/2023-04-fix-async-event-processing

Allow async events processing without holding `total_consistency_lock`

Merge pull request #2208 from wpaulino/monitor-rebroadcast-pending-claims

Implement pending claim rebroadcast on force-closed channels

Call ChainMonitor::rebroadcast_pending_claims on REBROADCAST_TIMER tick

This will prompt monitors to rebroadcast/fee-bump their pending claims
on a force-closed channel once on startup and every 30 seconds after.

Implement pending claim rebroadcast on force-closed channels

This attempts to rebroadcast/fee-bump each pending claim a monitor is
tracking for a force-closed channel. This is crucial in preventing
certain classes of pinning attacks and ensures reliability if
broadcasting fails. For implementations of `FeeEstimator` that also
support mempool fee estimation, we may broadcast a fee-bumped claim
instead, ensuring we can also react to mempool fee spikes between
blocks.

Extend OnchainTxHandler::generate_claim to optionally force feerate bump

In the next commit, we plan to extend the `OnchainTxHandler` to retry
pending claims on a timer. This timer may fire with much more frequency
than incoming blocks, so we want to avoid manually bumping feerates
(currently by 25%) each time our fee estimator provides a lower feerate
than before.

Fix outbound_payment for new Path::blinded_tail

Update changelog for backwards compat

Account for Path::blinded_tail when adding a shadow cltv offset

Test scoring paths with blinded tails

Account for Path::blinded_tail in InflightHtlcs::process_path

Support (de)serializing Path::blinded_tails in HTLCSource

Support (de)serializing Path::blinded_tails in Routes

Support (de)ser for Path::blinded_tails in events

Add blinded path {metadata} fields to Path, but disallow paying blinded paths for now

Merge pull request #2210 from alandotcom/patch-1

Fix README typo

Fix README typo

Clean up handshake timeout disconnection log message

It currently reads "disconnected from peer which hasn't completed
handshake due to ping timeout", which is confusing.

Instead, it will now read "disconnected from peer which hasn't
completed handshake due to ping/handshake timeout"

Allow events processing without holding `total_consistency_lock`

Unfortunately, the RAII types used by `RwLock` are not `Send`, which is
why they can't be held over `await` boundaries. In order to allow
asynchronous events processing in multi-threaded environments, we here
allow to process events without holding the `total_consistency_lock`.

Replace Vec<RouteHop> with new Path struct

This lays groundwork for adding blinded path info to Path

Add utilities for getting a path's final value and cltv delta

Minor Route/RouteHop doc updates

Clarify the error message when we disconnect a peer

We very regularly receive confusion over the super generic
"Peer sent invalid data or we decided to disconnect due to a
protocol error" message, which doesn't say very much. Usually, we
end up disconnecting because we have a duplicate connection with a
peer, which doesn't merit such a scary message.

Instead, here we clarify the error message to just refer to the
fact that we're disconnecting, and note that its usually a dup
connection in a parenthetical.

Fix BP prune timer and don't panic on persistence notification failure

Merge pull request #2205 from wpaulino/sign-ecdsa-with-noncedata

Generate local signatures with additional randomness

Use new feature to gate test vectors behind

To match the local signatures found in test vectors, we must make sure
we don't use any additional randomess when generating signatures, as
we'll arrive at a different signature otherwise.

Sign gossip messages without grinding low R signatures

Gossip messages always use signatures in their compact form, so grinding
for low R signatures is unnecessary.

Generate local signatures with additional randomness

Previously, our local signatures would always be deterministic, whether
we'd grind for low R value signatures or not. For peers supporting
SegWit, Bitcoin Core will generally use a transaction's witness-txid, as
opposed to its txid, to advertise transactions. Therefore, to ensure a
transaction has the best chance to propagate across node mempools in the
network, each of its broadcast attempts should have a unique/distinct
witness-txid, which we can achieve by introducing random nonce data when
generating local signatures, such that they are no longer deterministic.

Implement EntropySource for InMemorySigner

This allows the `InMemorySigner` to produce its own randomness, which we
plan to use when generating signatures in future work.

We can no longer derive `Clone` due to the `AtomicCounter`, so we opt to
implement it manually.

Merge pull request #2206 from jkczyz/2023-04-invoice-description

Expose description from Invoice's offer/refund

outbound_payment: remove unused cltv delta var

Extract read/write variants from impl_for_vec

We'll need to (de)serialize vecs of BlindedPaths differently based on whether
we're writing or reading

Update PaymentParameters::route_hints for blinded paths

Update docs and method names for blinded payment paths

Move blinded_path and its utils into a new module

Expose description from Invoice's offer/refund

This will allow clients like VLS to check the description for an invoice
as part of verification.

Merge pull request #1989 from jkczyz/2023-01-stateless-offers

Stateless BOLT 12 message verification

DRY up InvoiceFields construction

Support responding to refunds with transient keys

Extract keys from Offer::metadata to sign Invoice

For offers where the signing pubkey is derived, the keys need to be
extracted from the Offer::metadata in order to sign an invoice.
Parameterize InvoiceBuilder such that a build_and_sign method is
available for this situation.

DRY up verification of invreq TLV records

Stateless verification of Invoice for Refund

Stateless verification of Invoice for Offer

Verify that an Invoice was produced from a Refund constructed by the
payer using the payer metadata reflected in the Invoice. The payer
metadata consists of a 128-bit encrypted nonce and possibly a 256-bit
HMAC over the nonce and Refund TLV records (excluding the payer id)
using an ExpandedKey.

Thus, the HMAC can be reproduced from the refund bytes using the nonce
and the original ExpandedKey, and then checked against the metadata. If
metadata does not contain an HMAC, then the reproduced HMAC was used to
form the signing keys, and thus can be checked against the payer id.

Refund metadata and payer id derivation

Add support for deriving a transient payer id for each Refund from an
ExpandedKey and a nonce. This facilitates payer privacy by not tying any
Refund to any other nor to the payer's node id.

Additionally, support stateless Invoice verification by setting payer
metadata using an HMAC over the nonce and the remaining TLV records,
which will be later verified when receiving an Invoice response.

Stateless verification of Invoice for Offer

Verify that an Invoice was produced from an InvoiceRequest constructed
by the payer using the payer metadata reflected in the Invoice. The
payer metadata consists of a 128-bit encrypted nonce and possibly a
256-bit HMAC over the nonce and InvoiceRequest TLV records (excluding
the payer id) using an ExpandedKey.

Thus, the HMAC can be reproduced from the invoice request bytes using
the nonce and the original ExpandedKey, and then checked against the
metadata. If metadata does not contain an HMAC, then the reproduced HMAC
was used to form the signing keys, and thus can be checked against the
payer id.

Fix builder docs in offers module

InvoiceRequest metadata and payer id derivation

Add support for deriving a transient payer id for each InvoiceRequest
from an ExpandedKey and a nonce. This facilitates payer privacy by not
tying any InvoiceRequest to any other nor to the payer's node id.

Additionally, support stateless Invoice verification by setting payer
metadata using an HMAC over the nonce and the remaining TLV records,
which will be later verified when receiving an Invoice response.

Refactor InvoiceRequestContents fields into a sub-struct

InvoiceRequestBuilder has a field containing InvoiceRequestContents.
When deriving the payer_id from the remaining fields, a struct is needed
without payer_id as it not optional. Refactor InvoiceRequestContents to
have an inner struct without the payer_id such that
InvoiceRequestBuilder can use it instead.

Stateless verification of InvoiceRequest

Verify that an InvoiceRequest was produced from an Offer constructed by
the recipient using the Offer metadata reflected in the InvoiceRequest.
The Offer metadata consists of a 128-bit encrypted nonce and possibly a
256-bit HMAC over the nonce and Offer TLV records (excluding the signing
pubkey) using an ExpandedKey.

Thus, the HMAC can be reproduced from the offer bytes using the nonce
and the original ExpandedKey, and then checked against the metadata. If
metadata does not contain an HMAC, then the reproduced HMAC was used to
form the signing keys, and thus can be checked against the signing
pubkey.