Introduce ChannelSignerType.

Rather than using a holder_signer of a specific
signer type in Channel and ChannelContext, this
allows us to hold an enum such that depending on
the type of channel, the appropriate signer could
be held in its respective variant.

Doing so required the reparametrization of Channel
from using a Signer to using the SignerProvider
trait. This percolated down to the ChannelManager
and multiple tests.

Now, when accessign various signer methods, there
is a distinction between accessing methods defined
for all signers on ChannelSigner, and accessing
type-specific methods using accessors such as
`as_ecdsa`.

Fix bench lifetimes.

Benchmarks were failing because node config and
channel monitor configs were tied to the same
lifetime.

Introducing a separate lifetime allows to avoid
out-of-order deallocation errors.

Add Taproot feature support.

Introduce a Taproot feature on bits 30/31 for
initialization, node, and channel type contexts.

Fix persister/chain_monitor lifetimes.

The persister and chain_monitor variables must
be declared before the node channel manager is
initialized to avoid out of order deallocation.

Merge pull request #2498 from arik-so/arik/2023-08-gossip-logging

Improve network graph update logging

Merge pull request #2478 from waterson/settle-htlcs

Provide the HTLCs that settled a payment.

Merge pull request #2112 from TheBlueMatt/2023-02-sent-persist-order

Delay RAA-after-next processing until PaymentSent is are handled

Provide the HTLCs that settled a payment.

Creates a new `events::ClaimedHTLC` struct that contains the relevant
information about a claimed HTLC; e.g., the channel it arrived on, its ID, the
amount of the HTLC, the overall amount of the payment, etc. Adds appropriate
serialization support.

Adds a `Vec<events::ClaimedHTLC>` to the `ClaimingPayment`
structure. Populates this when creating the struct by converting the
`payment.htlcs` (which are `ClaimingHTLC` structs) into `event::ClaimedHTLC`
structs. This is a straightforward transformation.

Adds a `Vec<events::ClaimedHTLC>` to the `events::Event::PaymentClaimed`
enum. This is populated directly from the `ClaimingPayment`'s `htlcs` vec.

Fixes #2477.

Delay RAA-after-next processing until PaymentSent is are handled

In 0ad1f4c943bdc9037d0c43d1b74c745befa065f0 we fixed a nasty bug
where a failure to persist a `ChannelManager` faster than a
`ChannelMonitor` could result in the loss of a `PaymentSent` event,
eventually resulting in a `PaymentFailed` instead!

As noted in that commit, there's still some risk, though its been
substantially reduced - if we receive an `update_fulfill_htlc`
message for an outbound payment, and persist the initial removal
`ChannelMonitorUpdate`, then respond with our own
`commitment_signed` + `revoke_and_ack`, followed by receiving our
peer's final `revoke_and_ack`, and then persist the
`ChannelMonitorUpdate` generated from that, all prior to completing
a `ChannelManager` persistence, we'll still forget the HTLC and
eventually trigger a `PaymentFailed` rather than the correct
`PaymentSent`.

Here we fully fix the issue by delaying the final
`ChannelMonitorUpdate` persistence until the `PaymentSent` event
has been processed and document the fact that a spurious
`PaymentFailed` event can still be generated for a sent payment.

The original fix in 0ad1f4c943bdc9037d0c43d1b74c745befa065f0 is
still incredibly useful here, allowing us to avoid blocking the
first `ChannelMonitorUpdate` until the event processing completes,
as this would cause us to add event-processing delay in our general
commitment update latency. Instead, we ultimately race the user
handling the `PaymentSent` event with how long it takes our
`revoke_and_ack` + `commitment_signed` to make it to our
counterparty and receive the response `revoke_and_ack`. This should
give the user plenty of time to handle the event before we need to
make progress.

Sadly, because we change our `ChannelMonitorUpdate` semantics, this
change requires a number of test changes, avoiding checking for a
post-RAA `ChannelMonitorUpdate` until after we process a
`PaymentSent` event. Note that this does not apply to payments we
learned the preimage for on-chain - ensuring `PaymentSent` events
from such resolutions will be addressed in a future PR. Thus, tests
which resolve payments on-chain switch to a direct call to the
`expect_payment_sent` function with the claim-expected flag unset.

Pass `OutPoint`, rather than channel id to `claim_funds_internal`

This is a trivial refactor which will be used in the next commit.

Merge pull request #2506 from tnull/2023-08-dont-leak-internal-macros

Don't require import of internal macro for `impl_writeable_tlv_based`

Improve network graph update logging.

Don't require import of internal macros

Commit f560320b introduced changes that require users of
`impl_writeable_tlv_based`/`impl_writeable_tlv_based_enum` to import
`_encode_varint_length_prefixed_tlv` and `alloc` separately.

Here, we take care of the necessary imports in
`_encode_varint_length_prefixed_tlv` itself, allowing users to just
import the `impl_writeable_tlv_based` variant they need.

Merge pull request #2501 from TheBlueMatt/2023-08-err-pre-accept

Ensure we wipe pending un-accepted channel requests on err/discon.

Update documentation on `Channel::set_outbound_scid_alias`

...and replace an assertion with a debug_assertion

Merge pull request #2504 from alecchendev/2023-08-custom-tlvs-followup

Followup: custom HTLC TLVs

Address custom HTLC TLV fixups

Don't collect iterators to compare, minorly simplify encoding the
keysend TLV, combine the _encode_tlv_stream variants to check that the
ordering of TLVs is correct including custom TLVs.

Simplify custom HTLC TLV tests

Remove print statement, remove some unnecessary checks copied over from
test utils, make minor simplifications, wrap especially long lines.

Merge pull request #2500 from TheBlueMatt/2023-08-fix-test-lifetimes

Use more human-readable lifetime names in test structs

Correct test struct initialization ordering

When reloading a node in the test framework, we end up with a new
`ChannelManager` that has references to various test util structs.
In order for the tests to compile reliably in the face of unrelated
changes, those test structs need to always be initialized before
both the new but also the original `ChannelManager`.

Here we make that change.

Drop now-unused `outbound_scid_alias` param to channel constructor

01847277b957ec94129141a7e7439ae539c094f1 switched around the logic
for inbound channel construction to assign the outbound SCID alias
after constructing the `InboundV1Channel` object. Thus, the SCID
alias argument is now unused, and we remove it here.

Ensure we wipe pending un-accepted channel requests on err/discon.

If we have a pending inbound un-accepted channel but receive an
error message for it from our peer, or our peer disconnects, we
should remove the pending entry, ensuring any attempts to accept
it fail.

Merge pull request #2428 from waterson/create-channel-after-accept

Wait to create a channel until after accepting.

Merge pull request #2476 from wvanlint/remove_balance_msat

Remove AvailableBalances::balance_msat

Correct lifetimes on `_reload_node`

For some reason an unrelated PR caused all our tests with
`reload_node` calls to fail to compile. This is due, in part, to
the lifetimes on `reload_node` implying that the new and original
`ChannelManager` (or some of the structs they reference) must live
for the same lifetime.

This fixes that issue by correcting the lifetimes to be consistent
across `Node` and `_reload_node`.

Remove AvailableBalances::balance_msat

The ChannelMonitor::get_claimable_balances method provides a more
straightforward approach to the balance of a channel, which satisfies
most use cases. The computation of AvailableBalances::balance_msat is
complex and originally had a different purpose that is not applicable
anymore.

Merge pull request #2496 from dunxen/2023-08-fix2488

Send error message to peer if we drop an unfunded channel on timeout

Merge pull request #2458 from valentinewallace/2023-07-om-test-vectors

Onion message test vectors

Send error message to peer if we drop an unfunded channel on timeout

Wait to create a channel until after accepting.

Create a new table in 'peer_state' to maintain unaccepted inbound
channels; i.e., a channel for which we've received an 'open_channel'
message but that user code has not yet confirmed for acceptance. When
user code accepts the channel (e.g. via 'accept_inbound_channel'),
create the channel object and as before.

Currently, the 'open_channel' message eagerly creates an
InboundV1Channel object before determining if the channel should be
accepted. Because this happens /before/ the channel has been assigned
a user identity (which happens in the handler for OpenChannelRequest),
the channel is assigned a random user identity. As part of the
creation process, the channel's cryptographic material is initialized,
which then uses this randomly generated value for the user's channel
identity e.g. in SignerProvider::generate_channel_keys_id.

By delaying the creation of the InboundV1Channel until /after/ the
channel has been accepted, we ensure that we defer cryptographic
initialization until we have given the user the opportunity to assign
an identity to the channel.

Merge pull request #2387 from vladimirfomene/add_extra_fields_to_ChannelClosed_event

Add counterparty_node_id & channel_capacity to ChannelClosed event

Merge pull request #2308 from alecchendev/2023-05-custom-htlc-tlvs

Add support for custom HTLC TLVs

Merge pull request #1789 from jkczyz/2022-10-scorer-decay

Smooth out channel liquidity bounds decay

Merge pull request #2481 from TheBlueMatt/2023-08-keysend-robust-test

Scope payment preimage in do_test_keysend_payments

Enforce explicit claims on payments with even custom TLVs

Because we don't know which custom TLV type numbers the user is
expecting (and it would be cumbersome for them to tell us), instead of
failing unknown even custom TLVs on deserialization, we accept all
custom TLVs, and pass them to the user to check whether they recognize
them and choose to fail back if they don't. However, a user may not
check for custom TLVs, in which case we should reject any even custom
TLVs as unknown.

This commit makes sure a user must explicitly accept a payment with
even custom TLVs, by (1) making the default
`ChannelManager::claim_funds` fail if the payment had even custom TLVs
and (2) adding a new function
`ChannelManager::claim_funds_with_known_custom_tlvs` that accepts them.

This commit also refactors our custom TLVs test and updates various
documentation to account for this.

Add `FailureCode::InvalidOnionPayload` variant

When a user decodes custom TLVs, if they fail to recognize even type
numbers they should fail back with the correct failure code and fail
data. This new variant adds the proper failure variant for the user to
pass into `ChannelManager::fail_htlc_backwards_with_reason`.

Note that the enum discriminants were removed because when adding a
struct variant we can no longer make use of the discriminant through
casting like we previously did, and instead have to manually define the
associated failure code anyway.

Drop non-matching custom TLVs when receiving MPP

Upon receiving multiple payment parts with custom TLVs, we fail payments
if they have any non-matching or missing even TLVs, and otherwise just
drop non-matching TLVs if they're odd.

Handle receiving custom HTLC TLVs

This completes basic receiver-side support for custom TLVs and adds
functional testing for sending and receiving.

De/serialize custom TLVs on `{Inbound,Outbound}OnionPayload`

When serialized, the TLVs in `OutboundOnionPayload`, unlike a normal
TLV stream, are prefixed with the length of the stream. To allow a user
to add arbitrary custom TLVs, we aren't able to communicate to our
serialization macros exactly which fields to expect, so this commit
adds new macro variants to allow appending an extra set of bytes (and
modifying the prefixed length accordingly).

Because the keysend preimage TLV has a type number in the custom type
range, and a user's TLVs may have type numbers above and/or below
keysend's type number, and because TLV streams must be serialized in
increasing order by type number, this commit also ensures the keysend
TLV is properly sorted/serialized amongst the custom TLVs.

Add custom tlvs to `PendingOutboundPayment::Retryable`

Allow users to provide custom TLVs through `RecipientOnionFields`

Custom TLVs allow users to send extra application-specific data with
a payment. These have the additional flexibility compared to
`payment_metadata` that they don't have to reflect recipient generated
data provided in an invoice, in which `payment_metadata` could be
reused.

We ensure provided type numbers are unique, increasing, and within the
experimental range with the `RecipientOnionFields::with_custom_tlvs`
method.

This begins sender-side support for custom TLVs.

Merge pull request #2128 from valentinewallace/2023-03-route-blinding-groundwork

Route blinding groundwork

Smooth out channel liquidity bounds decay

Decaying the channel liquidity bounds by a half life can result in a
large decrease, which may have an oscillating affect on whether a
channel is retried. Approximate an additional three-quarter life when
half of the next half life has passed to help smooth out the decay.

Add test coverage ChannelClosed event fields

Add counterparty_node_id & channel_capacity to ChannelClosed

The current ChannelClosed event does not let
you know the counterparty during a channel close
event. This change adds the counterparty_node_id
and the channel_capacity to the ChannelClosed event.
This helps users to have more context during a
channel close event. Solves #2343

Make CI build -> test flows test -> build.

Doing `cargo test` causes us to build both the crate(s) themselves
and the test binaries, which depend on the main builds. However, it
can start building the test code while the actual program code for
the main crate(s) themselves are being built, making a
build -> test flow slightly slower than test -> build.

Its not really a huge deal, but I'm using `ci/ci-tests.sh` more
locally and it meaningfully changes the time-to-test-run.

Scope payment preimage in do_test_keysend_payments

b0d4ab8cf8c93740674a00546be38a1a5f0a83c3 fixed a nasty bug where
we'd failed to include the payment preimage in keysend onions at
all. Ultimately, this was a test failure - the existing test suite
should which did keysend payments were not structured in a way that
would fail in this case, instead using the same preimage variable
both for sending and receiving.

Here we improve the main keysend test tweaked by b0d4ab8cf8c9374067
to make absolutely sure it cannot work if the preimage doesn't come
from the onion. We make the payment preimage on the sending side a
variable inside a scope which only exists for the send call. Once
that scope completes the payment preimage only exists in the
sending `ChannelManager`, which must have put it in the onion in
order for the receiving node to have it.

Merge pull request #2475 from alecchendev/2023-08-actually-fix-keysend

Fix keysend not being sent in `OutboundPayment::send_payment_internal`

Send keysend preimage through OutboundPayment::send_payment_internal

Fixes a bug where we wouldn't use the provided keysend preimage when
piping through OutboundPayment::pay_route_internal.

Also simplifies and refactors existing keysend tests to make sure this
gets hit.

Move keysend tests to payment_tests.rs

Remove unnecessary vecs in channel.rs

Replace OnionHopData with OutboundPayload for outbound onions

Follows on from the previous commit, see its message

Receive payment onions as new InboundPayload instead of OnionHopData

To support route blinding, we want to split OnionHopData into two separate
structs, one for inbound onions and one for outbound onions. This is because
blinded payloads change the fields present in the onion hop data struct based
on whether we're sending vs receiving (outbound onions include encrypted blobs,
inbound onions can decrypt those blobs and contain the decrypted fields
themselves).

In upcoming commits, we'll add variants for blinded payloads to the new
InboundPayload enum.

Remove outdated documentation of a panic

Remove indentation in payment receive util

This also set us up for supporting receiving blinded onion payloads.

Merge pull request #2366 from valentinewallace/2023-05-blinded-pathfinding-fuzz

Blinded pathfinding fuzzing

Merge pull request #2460 from TheBlueMatt/2023-07-claimable-clarify

Rename `Balance::claimable_amount_satoshis` to have a unique name

Merge pull request #2463 from TheBlueMatt/2023-07-no-rustdoc-unicode

Drop unicode in documentation

Merge pull request #2465 from alecchendev/2023-07-flip-keysend-feature-bit

Flip keysend feature bit on

Merge pull request #2454 from optout21/unused-use

(Minor) Remove an unused import (ChannelSigner)

Merge pull request #2459 from valentinewallace/2023-07-reconnect-peers-test-util

Struct-ify `reconnect_nodes` test util args

Flip keysend feature bit in node features

Drop unicode in documentation

Javadocs refuse unicode and as our rustdocs get copied over to Java
bindings (and thus get run through javadocs) we can't have unicode
in our rustdocs.

Drop `claimable` from `Balance::claimable_amount_satoshis` fields

In Java/TypeScript, we map enums as a base class and each variant
as a class which extends the base. In Java/TypeScript, functions
and fields share the same namespace, which means we cannot have
functions on an enum which have the same name as any fields in any
enum variants.

`Balance`'s `claimable_amount_satoshis` method aliases with fields
in each variant, and thus ultimately doesn't compile in TypeScript.

Because `Balance::claimable_amount_satoshis` has the same name as
the fields, it's also a bit confusing, as it doesn't return the
field for each variant, but sometimes returns zero if we're not
sure we can claim the balance.

Instead, we rename the fields in each enum variant to simply
`amount_satoshis`, to avoid implying that we can definitely claim
the balance.

Struct-ify reconnect_nodes test util args

Makes it easier to add new arguments without a ton of resulting test changes.
Useful for route blinding testing because we need to check for malformed HTLCs,
which is not currently supported by reconnect_nodes. It also makes it easier to
tell what is being checked in relevant tests.

Add onion message test vectors

Also re-alphabetize the imports in the onion message functional tests.

Co-authored-by: Carla Kirk-Cohen <kirkcohenc@gmail.com>

Merge pull request #2104 from douglaz/docs_fixes_channel

Docs improvements for channel

Remove an unused use (ChannelSigner)

Fuzz test blinded payment pathfinding

Router fuzz: macroize first/last hops construction and pathfinding call

For reuse in fuzzing blinded payment pathfinding, and to ensure fuzz input
values are fetched in the same order in both match arms.

Docs improvements for channel

Merge pull request #2446 from TheBlueMatt/2023-07-ci-more-test

Run all tests first before testing more esoteric flags in CI

Merge pull request #2448 from TheBlueMatt/2023-07-cm-clone

Impl clone for ChannelMonitor

Merge pull request #2370 from valentinewallace/2023-06-send-along-path-args

Update `send_payment_along_path` to take its args as struct

Impl clone for ChannelMonitor

This gives people more freedom with the channel monitors. For Mutiny
this would be nice for us to be able to create copies of them and pass
aorund in memory without having to serialize until we actually want to.

Originally by benthecarman <benthecarman@live.com>
Small bugfix from Matt Corallo <git@bluematt.me>

Run all tests first before testing more esoteric flags in CI

This should at least marginally more aggressively target things
which are more likely to have changed in CI, making `ci-tests.sh`
more useful as a "default" script for developers to run locally.

Merge pull request #2431 from arik-so/2023-07-public-excess-data

Merge pull request #2444 from szabgab/https

http => https

http => https

Merge pull request #2427 from TheBlueMatt/2023-07-cut-116

Release 0.0.116

Bump crate versions to 0.0.116 release

Add a warning on anchors and update 116 changelog for release

Add `lightning-background-processor` `no-std` feature

While this is generally uneccessary as users set the `no-std` or
`std` features on the `lightning` crate directly, having this
allows `lightning-background-processor` to be built by itself
without extra dep lines. Specifically, the bindings are moving to
using the `-Z avoid-dev-deps` option, which now causes
`lightning-background-processor` to fail to build directly.

Merge pull request #2436 from tnull/2023-07-improve-router-logging

Improve router logging and update documentation

Merge pull request #2439 from tnull/2023-05-fix-0conf-sigs-racing-confirms

Avoid panic when 0conf channel's ann. sigs race on-chain confirmation

Improve logging for ignored candiate hops

Previously, we barely gave any hints why we excluded certain hops during
pathfinding. Here, we introduce more verbose logging by a) accounting
how much candidates we ignored for which reasons and b) logging any
first/last/blinded hops we end up ignoring.

Fixes #1646.

Update outdated `router.rs` docs

As `RouteParameters` are not included anymore in
`Event::PaymentPathFailed` since 0.0.115, and we don't give value/payee
as immediate arguments to `find_route` anymore.

Merge pull request #2434 from TheBlueMatt/2023-07-116-bindings-part-2

0.0.116 Bindings Changes

Avoid `unwrap`ing in `get_announcement_sigs`

While this is currently not reachable, it's still cleaner to
avoid the `unwrap` and return `None` if `short_channel_id` hasn't been
set yet.

Avoid panic when 0conf channel's ann. sigs race on-chain confirmation

A channel's `short_channel_id` is currently only set when the funding
transaction is confirmed via `transactions_confirmed`, which might be
well after the channel initally becomes usable, e.g., in the 0conf case.

Previously we would panic due to a reachable `unwrap` when receiving a
counterparty's `announcement_signatures` message for a 0conf channel
pending confirmation on-chain.

Here we fix this bug by avoiding unsafe `unwrap`s and just erroring out
and ignoring the announcement_signatures message if the `short_channel_id`
hasn't been set yet.

Add relevant derives for `BigSize` as its a simple integer

Add relevant trait derives for `bump_transaction` structs

Notably including `Hash`/`Eq`/`Ord` for structs which may be used
in maps.

Make `OffersMessage` and offers errors `Clone`able

Make `requires_unknown_bits_from` param type bindings compatible

While bindings should probably be able to figure out that this is
the same type as `Self`, for now we simply swap the type to make
the bindings generator have an easier go of it.

Mark the `Duration` serialization implementation no-bindings-export

The bindings are being updated to consider all traits even if the
trait itself is no-export, which causes issues generating code
around the `Duration` impl here.

No-export un-exportable types in BOLT12 module

We missed one method that now cannot be bindings exported - the
`payment_paths` method, as it returns a slice of objects, which
cannot be supported in bindings.

No-export `APeerManager` in bindings

`APeerManager` will simply be mapped as `PeerManager` in bindings,
as structs are all concretized into a single form.

Move `ClaimId` to `[u8; 32]` in bindings.

This matches what we've done for other `[u8; 32]` newtypes.

Tweak PSBT signing for bindings compatibility

In bindings we can't practically pass a mutable PSBT, and instead
need to pass an owned transaction and have the sign method return a
signed copy. We do this here for all build modes as its not a
material API change for Rust users.