Introduce nonzero fee anchors feature.

Merge pull request #2089 from wpaulino/bump-transaction-event-handler

Add BumpTransaction event handler

Provide a default CoinSelectionSource implementation via a new trait

Certain users may not care how their UTXOs are selected, or their wallet
may not expose enough controls to fully implement the
`CoinSelectionSource` trait. As an alternative, we introduce another
trait `WalletSource` they could opt to implement instead, which is much
simpler as it just returns the set of confirmed UTXOs that may be used.
This trait implementation is then consumed into a wrapper `Wallet` which
implements the `CoinSelectionSource` trait using a "smallest
above-dust-after-spend first" coin selection algorithm.

Add BumpTransaction event handler

This allows users to bump their commitments and HTLC transactions
without having to worry about all the little details to do so. Instead,
we'll just require that they implement the `CoinSelectionSource` trait
over their wallet/UTXO source, granting the event handler permission to
spend confirmed UTXOs for the transactions it'll produce.

While the event handler should in most cases produce valid transactions,
assuming the provided confirmed UTXOs are valid, it may not produce
relayable transactions due to not satisfying certain Replace-By-Fee
(RBF) mempool policy requirements. Some of these require that the
replacement transactions have a higher feerate and absolute fee than the
conflicting transactions it aims to replace. To make sure we adhere to
these requirements, we'd have to persist some state for all transactions
the event handler has produced, greatly increasing its complexity. While
we may consider implementing so in the future, we choose to go with a
simple initial version that relies on the OnchainTxHandler's bumping
frequency. For each new bumping attempt, the OnchainTxHandler proposes a
25% feerate increase to ensure transactions can propagate under
constrained mempool circumstances.

Expose ClaimId for each claim bump in BumpTransactionEvent

Expose existing PackageID to API and rename to ClaimId

In a future commit, we plan to expand `BumpTransactionEvent` variants to
include the unique identifier assigned to pending output claims by the
`OnchainTxHandler` when a commitment is broadcast/confirmed. This
requires making it public in our API. We also choose to rename it to
`ClaimId` for the benefit of users, as the previous `PackageID` term
could be interpreted to be the ID of a BIP-331 transaction package.

Change package ID computation for HTLC claims on anchor channels

While the previous way of computing the identifier was safe, it wouldn't
have been in certain scenarios if we considered splitting aggregated
packages. While this type of splitting has yet to be implemented, it may
come in the near future. To ensure we're prepared to handle such, we
opt to instead commit to all of the HTLCs to claim in the request.

Merge pull request #2351 from TheBlueMatt/2023-04-remove-legacy-recv

Drop `create_inbound_payment*_legacy` breaking downgrade to 0.0.103

Merge pull request #2077 from dunxen/2023-02-splitchannelstate

Split prefunded `Channel` into `Inbound`/`Outbound` channels

Rename `inbound_is_awaiting_accept()` to `is_awaiting_accept()`

Rename `InboundV1Channel::new_from_req` to `InboundV1Channel::new`

Move inbound channel methods into `InboundV1Channel`'s impl

Move outbound channel methods into `OutboundV1Channel`'s impl

Create and use methods for counting channels

This commit also adds two new maps to `PeerState` for keeping track
of `OutboundV1Channel`s and `InboundV1Channel`s so that further
commits are a bit easier to review.

Refactor channel map update macros for use with `ChannelContext`

Move `Channel::force_shutdown` to `ChannelContext` impl

Move inbound channel constructor into `InboundV1Channel` impl

Move outbound channel constructor into `OutboundV1Channel` impl

Introduce `InboundV1Channel` & `OutboundV1Channel`

Move channel constants up

Make `ChannelManager::issue_channel_close_events` take a `ChannelContext`

Convert `ChannelDetails::from_channel` to `ChannelDetails::from_channel_context`

This rename and refactor is so that we can get channel details from a
`ChannelContext` which is a common object to all channels.

Move `Channel::get_available_balances` to `ChannelContext` impl

Move `Channel::next_*_commit_tx_fee_msat` methods to `ChannelContext` impl

Move `Channel::commit_tx_fee_msat` to file-level utilities

Move `Channel::get_*_pending_htlc_stats` to `ChannelContext` impl

Prepare some methods for upcoming moves to `ChannelContext`

To reduce interleaving in commits, we introduce a `context` variable
in methods to be moved in upcoming commits so there is minimal change
with the moves.

Move `Channel::get_feerate_sat_per_1000_weight` and other methods

This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields to be updated for things to
compile, but these should be quite clear.

This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.

f s/tarcontext.get_/target_/

Move `Channel::build_holder_transaction_keys` and some other methods

This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.

This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.

Move `Channel::build_commitment_transaction` to `ChannelContext` impl

This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.

This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.

Move `Channel::channel_id` and some other methods to `ChannelContext` impl

This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.

This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.

Move `Channel::get_update_time_counter` and some other methods

This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.

This commit also uses these methods through the `context` field where
needed for compilation and tests to pass due to the above change.

Move `Channel::opt_anchors` to `ChannelContext` impl & move some util fns

This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.

Move `Channel` fields into `ChannelContext` struct

This is a first step for simplifying the channel state and introducing
new unfunded channel types that hold similar state before being promoted
to funded channels.

Essentially, we want the outer `Channel` type (and upcoming channel types)
to wrap the context so we can apply typestate patterns to the that wrapper
while also deduplicating code for common state and other internal fields.

Merge pull request #2294 from jkczyz/2023-05-onion-message-replies

BOLT 12 Offers message handling support

Reduce log level of potential noisy log statement

Fuzz test onion message replies

Use different node secrets in onion message fuzzer

When generating onion message fuzz data, the same public key was used
for each node. However, the code now advances the blinded path if the
sender is the introduction node. Use different node secrets for each
node to avoid this. Note that the exercised handling code is for the
sender's immediate peer.

Test onion message replies

Split TestCustomMessage into Request and Response

This will allow for testing onion message replies.

Remove unnecessary Sized bound

Support onion message replies in OnionMessenger

Modify onion message handlers to return an optional response message for
OnionMessenger to reply with.

MessageRouter trait for OnionMessenger

Add a trait for finding routes for onion messages and parameterize
OnionMessenger with it. This allows OnionMessenger to reply to messages
that it handles via one of its handlers (e.g., OffersMessageHandler).

Add OnionMessagePath wrapper struct

To avoid confusion in the upcoming MessageRouter trait, introduce an
OnionMessagePath struct that wraps the intermediate nodes and the
destination. Use this in OnionMessenger::send_onion_message.

OffersMessageHandler trait for OnionMessenger

Add a trait for handling BOLT 12 Offers messages to OnionMessenger and a
skeleton implementation of it for ChannelManager. This allows users to
either provide their own custom handling Offers messages or rely on a
version provided by LDK using stateless verification.

Avoid an unnecessary unwrap

Onion message payload for BOLT 12 Offers

BOLT 12 Offers makes use of onion messages to request and respond with
invoices. Add these types and an error type to OnionMessageContents
along with the necessary parsing and encoding.

Pass logger to onion payload decoder

In an upcoming commit, messages for BOLT 12 offers are read from the
onion payload. Passing a logger allows for logging semantic errors when
parsing the messages.

Add InvoiceError message

If an InvoiceRequest or an Invoice delivered via an onion message cannot
be handled, the recipient should reply with an InvoiceError if a reply
path was given. Define the message and conversion from SemanticError.

Support WithoutLength for UntrustedString

Merge pull request #2353 from TheBlueMatt/2023-06-fix-msrv-build

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.

Stop writing old `user_payment_id` field not read since 0.0.103

Since we're breaking downgrade compatibility to LDK version 0.0.103
and before, we might as well go ahead and remove other code we have
for compatibility.

Drop `create_inbound_payment*_legacy` breaking downgrade to 0.0.103

0.0.103 is now downright ancient, and certainly shouldn't exist in
production anywhere today. Thus, it seems fine to remove the
ability to create legacy stateful inbound payment entries.

Users downgrading to 0.0.103 will thus not be able to claim any
payments created on modern LDK, though we still retain the ability
to claim such payments at least for one more release.

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