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.

Consider HTLC in-flight count limits 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 the number of in-flight HTLCs which we are allowed
to push towards a counterparty at once, setting the available
balance to zero if we cannot push any further HTLCs.

We also add some testing when sending to ensure that send failures
are accounted for in our balance calculations.

Consider commitment tx fee while 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 include the cost of the commitment transaction fee in our
calculation, subtracting the commitment tx fee cost from the
available as we do in `send_payment`.

We also add some testing when sending to ensure that send failures
are accounted for in our balance calculations.

This commit is based on original work by
Gleb Naumenko <naumenko.gs@gmail.com> and modified by
Matt Corallo <git@bluematt.me>.

Simplify test_fail_holding_cell_htlc_upon_free_multihop somewhat

In the coming commits we redo our next-HTLC-available logic which
requires some minor test changes for tests which relied on
calculating routes which were not usable.

Here we do a minor prefactor to simplify a test which now no longer
requires later changes.

Disallow sending an HTLC when the balance needed is pending removal

While its nice to be able to push an HTLC which spends balance that
is removed in our local commitment transaction but awaiting an RAA
from our peer for final removal its by no means a critical feature.

Because peers should really be sending RAAs quickly after we send
a commitment, this should be an exceedingly rare case, and we
already don't expose this as available balance when routing, so
this isn't even made available when sending, only forwarding.

Note that `test_pending_claimed_htlc_no_balance_underflow` is
removed as it tested a case which was only possible because of this
and now is no longer possible.

Merge pull request #2272 from benthecarman/package-broadcast

Support broadcasting multiple transactions at once

Merge pull request #2235 from TheBlueMatt/2023-04-criterion

Replace std's unmaintained bench with criterion

Merge pull request #2226 from alecchendev/2023-04-persist-network-graph-on-rgs

Update BP `NetworkGraph` and `Scorer` persist frequency

Merge pull request #2204 from jkczyz/2023-04-custom-feature-bits

Support for custom feature bits

Merge pull request #1841 from ariard/2022-11-revoked-balance-non-aggregable

Post-anchor: do not aggregate claim of revoked output

Remove aggregable flag from PackageTemplate constructor

Anchor: do not aggregate claim of revoked output

See https://github.com/lightning/bolts/pull/803

This protect the justice claim of counterparty revoked output. As
otherwise if the all the revoked outputs claims are batched in a
single transaction, low-feerate HTLCs transactions can delay our
honest justice claim transaction until BREAKDOWN_TIMEOUT expires.

Persist scorer upon update based on event handling

Now that we persist the scorer upon events, we extend timer persistence
from 30 seconds to 1 hour, similar to network graph persistence.

Prune and persist RGS network graph after initial sync

Previously we would wait 60 seconds after startup, however for RGS we
prune/persist after its initial sync since 60 seconds is likely too
long.

Merge pull request #2288 from wpaulino/rust-bitcoin-30-prereqs

Support broadcasting multiple transactions at once

Merge pull request #2271 from tnull/2023-04-fix-onion-panic

Return error when failing onion packet construction

Merge pull request #2286 from benthecarman/spendable-outputs-psbt

Create and Sign PSBTs for spendable outputs

Return error when failing to construc onion messages

Previously, we would panic when failing to construct onion messages in
certain circumstances. Here we opt to always rather error out and don't
panic if something goes wrong during OM packet construction.

Update .gitignore to ignore benchmark data files

Add trivial README to bench to describe how to run them.

Replace std's unmaintained bench with criterion

Rather than using the std benchmark framework (which isn't
maintained and is unlikely to get any further maintenance), we swap
for criterion, which at least gets us a variable number of test
runs so our benchmarks don't take forever.

We also fix the RGS benchmark to pass now that the file in use is
stale compared to today's date.

Add an additional test/bench for routing larger amounts, score more

When benchmarking our router, we previously only ever tested with
amounts under 1,000 sats, which is an incredibly small amount.
While this ensures we have the maximal number of available channels
to consider, it prevents our scorer from getting exercise across
its range. Further, we only score the immediate path we are
expecting to to send over, and not randomly but rather based on the
amount sent.

Here we try to make the benchmarks a bit more realistic by adding
a new benchmark which attempts to send around 100K sats, which is
a reasonable amount to send over a channel today. We also convert
the scoring data to be randomized based on the seed as well as
attempt to (possibly) find a new route for a much larger value and
score based on that. This potentially allows us to score multiple
potential paths between the source and destination as the large
route-find may return an MPP result.

Unify route benchmarking with route tests

There's a few route tests which do the same thing as the benchmarks
as they're also a good test. However, they didn't share code, which
is somewhat wasteful, so we fix that here.

Merge pull request #2237 from henghonglee/issue-2189-score-params

[#2189] Score Fee Params as a passed in parameter

Create and Sign PSBTs for spendable outputs

Move functions around to colocate impl of FeeParams and DecayParams

Score's FeeParams as passed-in params on Routefinding functions

This PR aims to create a "stateless" scorer. Instead of passing
in fee params at construction-time, we want to parametrize the
scorer with an associated "parameter" type, which is then
passed to the router function itself, and allows passing
different parameters per route-finding call.

Update missed comment in Features test

Add Features::set_{required|optional}_custom_bit

Custom message handlers may need to set feature bits that are unknown to
LDK. Provide Features::set_required_custom_bit and
Features::set_optional_custom_bit to allow for this.

Check unknown features compared to handlers

Each message handler provides which features it supports. A custom
message handler may support unknown features. Therefore, these features
should be checked against instead of the features known by LDK.
Additionally, fail the connection if the peer requires features unknown
to the handler. The peer should already fail the connection in the
latter case.

Fix test_restored_packages_retry serialized monitor payload

The purpose of this payload is to ensure we retry restored packages on a
`ChannelMonitor` that has upgraded from a version that previously did
not have such retry logic. We can verify this works by checking whether
a restored package has a `height_timer` of `None` upon deserializing the
monitor payload.

In the previous commit, we added a helper that constructs blocks
whenever tests demand blocks be connected. This helper moved towards
having all connected blocks have a version of 0x2000_0000 (also known as
NO_SOFT_FORK_SIGNALLING). However, previously, it was possible for some
blocks to be connected with a slighty different version: 0x0200_0000,
resulting in different block hashes.

This block hash divergence prompted a failure in this test when
`ConnectStyle::HighlyRedundantTransactionsFirstSkippingBlocks` is used
for `nodes[0]`, since this block connection style reconfirms
transactions redundantly and the serialized monitor payload kept a
reference to the hash of the block with version 0x0200_0000, when it
should be expecting one with version 0x2000_0000.

Use helper to create dummy blocks

`rust-bitcoin v0.30.0` introduces concrete variants for data members of
block `Header`s. To avoid having to update these across every use, we
introduce new helpers to create dummy blocks and headers, such that the
update process is a bit more straight-forward.

Check difficulty transition against `Target` instead of `Work`

`rust-bitcoin v0.30.0` made some changes in this area that no longer
allow us to work with the previously exposed `U256` type. While `Work`
and `Target` (they're inverses of each other) essentially represent the
same concept, it makes more sense from their API's perspective to only
expose difficulty transitions and adjustments on `Target`s.

Ignore lightning-transaction-sync build output

Merge pull request #2279 from benthecarman/ord-invoice

Impl PartialOrd and Ord for Invoice

Merge pull request #2287 from TheBlueMatt/2023-05-no-background-event-dup-persist

Stop persisting background shutdown monitor updates

Rename ClosingMonitorUpdate MonitorUpdateRegeneratedOnStartup

This makes much clearer at sites generating such events that they
will be lost on restart, to reduce risk of bugs creeping in due to
lost monitor updates.

Stop persisting background shutdown monitor updates

In d4810087c1 we added logic to apply `ChannelMonitorUpdate`s which
were a part of a channel closure async via a background queue to
address some startup issues. When we did that we persisted those
updates to ensure we replayed them when starting next time.

However, there was no reason to - if we persisted and then
restarted even without those monitor updates we'd find a monitor
without a channel, which we'd tell to broadcast the latest
commitment transaction to force-close.

Since adding that logic, we've used the same background queue for
several purposes.

Impl PartialOrd and Ord for Invoice

Merge pull request #2281 from dunxen/2023-05-dfmsgfollowups

Dual funding message follow-ups

Merge pull request #2270 from tnull/2023-05-improve-tx-sync-compat-notice

Make `lightning-transaction-sync` compat notice a bit more explicit

Merge pull request #2278 from benthecarman/faster-u16-check

Check too many tx outputs upfront when verifying funding tx

Merge pull request #2277 from valentinewallace/2023-05-fix-big-oms

Fix large onion message packet generation

Make `lightning-transaction-sync` compat notice a bit more explicit

As `lightning-transaction-sync` was introduced with 0.0.114 and depended
on prior changes in the same release cycle we deemed it reasonable to
omit the implicitly limited backwards compatibility.

It however turns out this might be confusing to users copy/pasting the
codebase. Here we therefore spell out the implicit dependency on 0.0.114
and above.

Enforce that no bytes remain for TransactionU16LenLimited read

Move TransactionU16LenLimited to ser.rs

Merge pull request #2258 from valentinewallace/2023-04-blinded-pathfinding-groundwork-2

Prefactor `PaymentParameters` for blinded recipients

Check too many tx outputs upfront when verifying funding tx

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

Fix onion messages of size BIG_PACKET_HOP_DATA_LEN

This was previously broken and would result in an invalid HMAC error, because
we had a hardcoded assumption that OM hop data would always be of size 1300.

Fix broken test utils in OnionMessenger and stop asserting on logs

Merge pull request #1794 from dunxen/2022-10-dualfunding-act-1

Dual funding and interactive tx construction wire messages

Merge pull request #2269 from TheBlueMatt/2023-05-doc-events-present

Document when event fields are `Some`

Merge pull request #2265 from wpaulino/channel-force-closed-update-err

Prevent ChannelForceClosed monitor update error after detecting spend

Add Features::requires_unknown_bits_from

When checking features, rather than checking against which features LDK
knows about, it is more useful to check against a peer's features. Add
Features::requires_unknown_bits_from such that the given features are
used instead.

Add PeerManager::init_features to DRY up code

Provide features in CustomMessageHandler

CustomMessageHandler implementations may need to advertise support for
features. Add methods to CustomMessageHandler to provide these and
combine them with features from other message handlers.

Define core::ops::BitOr for Features<T>

The `lightning-custom-message` crate will need access to Features::or in
order combine features of a composite handler. Expose this via a
core::ops::BitOr implementation.

Merge pull request #2267 from TheBlueMatt/2023-05-better-scb-err

Mention lnd's SCB feature in the corresponding error message

Add & generate dual-funding message fuzzing

Add new wire messaging and events but don't handle them

Add message structs required for dual-funded channels

This is the first of a set of PRs to enable the experimental dual-funded
channels feature using interactive transaction construction. This allows
both the channel initiator and channel acceptor to contribute funds
towards the channel.

Docuemnt when `PaymentPathFailed::payment_id` is `Some`

The `PaymentPathFailed::payment_id` field has been `Some` since
the field was added in
73f601fd3d1c9defe553392264ca6dbcc53e4334.

Document when `PaymentPathSuccessful::payment_hash` is filled in.

The `payment_hash` field in `PaymentPathSuccessful` is always
`Some` as long as the pening payment tracker has a `payment_hash`,
which is true for all `Pending` payments as well as all `Fulfilled`
payments starting with the commit which added
`PaymentPathSuccessful` -
3b5c370b404e2f5a8f3c35093b97406f149a9340c177c05252574083d68df0da.

Improve logging around redundant force close monitor updates

Mention lnd's SCB feature in the corresponding error message

It's a bit confusing when we see only "Peer sent a garbage
channel_reestablish" when a peer uses lnd's SCB feature to ask us
to broadcast the latest state. This updates the error message to be
a bit clearer.

Prevent ChannelForceClosed monitor update error after detecting spend

If we detected a spend for a channel onchain prior to handling its
`ChannelForceClosed` monitor update, we'd log a concerning error
message and return an error unnecessarily. The channel has already been
closed, so handling the `ChannelForceClosed` monitor update at this
point should be a no-op.

Merge pull request #2111 from TheBlueMatt/2023-03-sent-persist-order-prep

Setup Support for delaying `ChannelMonitorUpdate` flight until an `Event` completes

Merge pull request #2262 from Kixunil/remove-serde-error-allocation

Remove unneeded allocation

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.

Remove unneeded allocation

`<E as serde::de::Error>::custom()` accepts any `T: Display`, not just
`String`. Therefore it accepts `Arguments<'_>` too so we can use
`format_args!()` instead of `format!()`.

See https://github.com/lightningdevkit/rust-lightning/pull/2187#discussion_r1168781355

Merge pull request #2246 from arik-so/2023-04-sign-module

Move keysinterface.rs to a directory-level module called sign

Merge pull request #2219 from benthecarman/custom-closing-address

Add ability to set shutdown script when closing channel

Move keysinterface.rs to a directory-level module called sign.

Merge pull request #2249 from TheBlueMatt/2023-04-less-pm-bounds

Trivial PeerManager cleanups

Expose a trait impl'd for all `PeerManager` for use as a bound

A while back, in tests, we added a `AChannelManager` trait, which
is implemented for all `ChannelManager`s, and can be used as a
bound when we need a `ChannelManager`, rather than having to
duplicate all the bounds of `ChannelManager` everywhere.

Here we do the same thing for `PeerManager`, but make it public and
use it to clean up `lightning-net-tokio` and
`lightning-background-processor`.

We should likely do the same for `AChannelManager`, but that's left
as a followup.

Merge pull request #2253 from dunxen/2023-05-removeoptionalfield

Remove `OptionalField` and make `DataLossProtect` fields mandatory

Add ability to set shutdown script when closing channel

Merge pull request #2244 from benthecarman/signature-size

Incorporate low-R values into estimate signature size

Set data_loss_protect_required

Store + process pending `ChannelMonitorUpdate`s in `Channel`

The previous commits set up the ability for us to hold
`ChannelMonitorUpdate`s which are pending until we're ready to pass
them to users and have them be applied. However, if the
`ChannelManager` is persisted while we're waiting to give the user
a `ChannelMonitorUpdate` we'll be confused on restart - seeing our
latest `ChannelMonitor` state as stale compared to our
`ChannelManager` - a critical error.

Luckily the solution is trivial, we simply need to store the
pending `ChannelMonitorUpdate` state and load it with the
`ChannelManager` data, allowing stale monitors on load as long as
we have the missing pending updates between where we are and the
latest `ChannelMonitor` state.

Handle `EventCompletionAction`s after events complete

This adds handling of the new `EventCompletionAction`s after
`Event`s are handled, letting `ChannelMonitorUpdate`s which were
blocked fly after a relevant `Event`.

Track an `EventCompletionAction` for after an `Event` is processed

This will allow us to block `ChannelMonitorUpdate`s on `Event`
processing in the next commit.

Note that this gets dangerously close to breaking forwards
compatibility - if we have an `Event` with an
`EventCompletionAction` tied to it, we persist a new, even, TLV in
the `ChannelManager`. Hopefully this should be uncommon, as it
implies an `Event` was delayed until after a full round-trip to a
peer.

Allow holding `ChannelMonitorUpdate`s until later, completing one

In the coming commits, we need to delay `ChannelMonitorUpdate`s
until future actions (specifically `Event` handling). However,
because we should only notify users once of a given
`ChannelMonitorUpdate` and they must be provided in-order, we need
to track which ones have or have not been given to users and, once
updating resumes, fly the ones that haven't already made it to
users.

To do this we simply add a `bool` in the `ChannelMonitorUpdate` set
stored in the `Channel` which indicates if an update flew and
decline to provide new updates back to the `ChannelManager` if any
updates have their flown bit unset.

Further, because we'll now by releasing `ChannelMonitorUpdate`s
which were already stored in the pending list, we now need to
support getting a `Completed` result for a monitor which isn't the
only pending monitor (or even out of order), thus we also rewrite
the way monitor updates are marked completed.

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

Allow get_shutdown_scriptpubkey and get_destination_script to return an Error

Remove `OptionalField` and move `shutdown_scriptpubkey` into TLV stream

As pointed out in https://github.com/lightning/bolts/pull/754/commits/6656b70,
we can move the `shutdown_scriptpubkey` field into the TLV streams of
`OpenChannel` and `AcceptChannel` without affecting the resulting encoding.

We use `WithoutLength` encoding here to ensure that we do not encode a
length prefix along with `Script` as is normally the case.

Allow get_shutdown_scriptpubkey and get_destination_script to return an error

Incorporate low-R values into estimate signature size

Make `DataLossProtect` fields required and remove wrappers

The fields provided by `DataLossProtect` have been mandatory since
https://github.com/lightning/bolts/pull/754/commits/6656b70, regardless
of whether `option_dataloss_protect` or `option_remote_key` feature bits
are set.

We move the fields out of `DataLossProtect` to make encoding definitions
more succinct with `impl_writeable_msg!` and to reduce boilerplate.

This paves the way for completely removing `OptionalField` in subsequent
commits.