Consolidate sign_closing_transaction callsites to get_closing_signed_msg

Merge pull request #3192 from jkczyz/2024-07-invoice-error-auth

Authenticate `InvoiceError` messages

Make PaymentFailureReason downgradable

The PaymentFailureReason variants for invoice request failures will
cause downgrades to break. Instead, use a new TLV for the reason and
continue to write the old TLV, only use None for the new reasons.

Make PaymentFailureReason upgradable

This allows downgrading to version 0.0.124 or later and using None for a
PaymentFailureReason that was added after.

Add PaymentFailureReason::InvoiceRequestRejected

Instead of re-using PaymentFailureReason::RecipientRejected, define a
new InvoiceRequestRejected variant for when an InvoiceError is received
instead of a Bolt12Invoice. This allows user to differentiate the cause
of the failure.

Add PaymentFailureReason::InvoiceRequestExpired

Now that Event::PaymentFailed is generated when an InvoiceRequest times
out, define a new PaymentFailureReason for this situation.

Add pending changelog for Event::PaymentFailed

Remove Event::InvoiceRequestFailed

Now that Event::PaymentFailed has an option payment_hash, it can be used
in replace of Event::InvoiceRequestFailed. This allows for including a
reason when abandoning a payment before an invoice is received.

Make payment_hash optional in Event::PaymentFailed

When abandoning a BOLT12 payment before a Bolt12Invoice is received, an
Event::InvoiceRequestFailed is generated and the abandonment reason is
lost. Make payment_hash optional in Event::PaymentFailed so that
Event::InvoiceRequestFailed can be removed in favor of it.

Test Bolt12Invoice with unknown required features

Remove unused macro param

Add InvoiceBuilder::features_unchecked

In order to test handling of unknown required features in a
Bolt12Invoice, add a test-only function to allow setting arbitrary
feature bits.

Use a smaller bit for UnknownFeature

When testing Bolt12Invoice unknown require feature handling, a large
feature bit can cause SendError::TooBigPacket when creating an onion
message. Use a smaller feature bit for UnknownFeature, which also has
the added benefit of reducing test output.

Move BOLT12 invoice features check

When handling a BOLT12 invoice, and invoice error is sent if the invoice
contains unknown required features. However, since the payment is still
in state AwaitingInvoice, abandoning it results in losing the reason
since an InvoiceRequestFailed event would be generated. Move the check
to PendingOutboundPayments such that the payment is first moved to state
InvoiceReceived so that a PaymentFailed event is generated instead.

Don't include HMAC in Refund paths

Refunds are typically communicated via QR code, where a smaller size is
desirable. Make the HMAC in OutboundPayment data optional such that it
is elided from blinded paths used in refunds. This prevents abandoning
refunds if the reader sends an invoice_error instead of an invoice
message. However, this use case isn't necessary as the corresponding
outbound payment will either timeout when the refund expires or can be
explicitly abandoned by the creator.

Don't use UserAbandoned reason for auto-failing

A BOLT12 payment may be abandoned when handling the invoice or when
receiving an InvoiceError message. When abandoning the payment, don't
use UserAbandoned as the reason since that is meant for when the user
calls ChannelManager::abandon_payment.

Don't abandon payments for duplicate invoices

When making an outbound BOLT12 payment, multiple invoices may be
received for the same payment id. Instead of abandoning the payment when
a duplicate invoice received, simply ignore it without responding with
an InvoiceError. This prevents abandoning in-progress payments and
sending unnecessary onion messages.

Authenticate payment_id from OffersContext

Before abandoning a payment when receiving an InvoiceError, verify that
the PaymentId included in the OffersContext with the included HMAC. This
prevents a malicious actor sending an InvoiceError with a known payment
id from abandoning our payment.

Add an HMAC to OffersContext::OutboundPayment

When receiving an InvoiceError in response to an InvoiceRequest, the
corresponding payment should be abandoned. Add an HMAC to
OffersContext::OutboundPayment such that the payment ID can be
authenticated prior to abandoning the payment.

Add Sha256 HMAC (de)serialization

An HMAC needs to be included in OffersContext::OutboundPayment to
authenticate the included PaymentId. Implement Readable and Writeable to
allow for this.

HMAC construction and verification for PaymentID

When receiving an InvoiceError in response to an InvoiceRequest, the
corresponding payment should be abandoned. Add functions for
constructing and verifying an HMAC over a Payment ID to allow for this.

Merge pull request #3212 from dunxen/2024-07-sensible-balances

Accuracy fixes and differentiating sources for `Balance`

Merge pull request #3234 from TheBlueMatt/2024-08-lightning-dep-inv

Swap the dep order between `lightning` and `lightning-invoice`

Merge pull request #3020 from tnull/2024-04-drop-electrsd-autodownload-for-good

Drop `electrsd`'s auto-download feature for good

Enable caching for `bitcoind`/`electrs` in CI

`rustfmt` new files added in the past few commits

The past handful of commits were mostly moving code around, so to
aid reviewers violated our `rustfmt` rules. Here we rectify that by
`rustfmt`'ing the newly-added files.

Prepare to `rustfmt` newly added files

In the next commit we'll `rustfmt` newly-added files, but before
we do so we clean up some code so that the resulting files won't be
quite as absurd. We also exclude the new `invoice_utils.rs` file,
as it needs quite substantial cleanups.

Provide the signer with a full `RawBolt11Invoice` to sign

Now that the `lightning` crate depends on the `lightning-invoice`
crate, there's no reason to have the `sign_invoice` method take raw
base32 field elements as we can now give it a real
`RawBolt11Invoice`, which we do here.

This simplifies the interface and avoids a
serialization-deserialization roundtrip when signing invoices in a
validating signer.

FIxes #3227

Swap the dep order between `lightning` and `lightning-invoice`

`lightning-invoice` previously had a dependency on the entire
`lightning` crate just because it wants to use some of the useful
types from it. This is obviously backwards and leads to some
awkwardness like the BOLT 11 invoice signing API in the `lightning`
crate taking a `[u5]` rather than a `Bolt11Invoice`.

Here we finally rectify this issue, swapping the dependency order
and making `lightning` depend on `lightning-invoice` rather than
the other way around.

This moves various utilities which were in `lightning-invoice` but
relied on `lightning` payment types to make payments to where they
belong (the `lightning` crate), but doesn't bother with integrating
them well in their new home.

Add a `lightning-types` dependency to `lightning-invoice`

`lightning-invoice` currently has a dependency on the entire
`lightning` crate just because it wants to use some of the useful
types from it. This is obviously backwards and leads to some
awkwardness like the BOLT 11 invoice signing API in the `lightning`
crate taking a `[u5]` rather than a `Bolt11Invoice`.

This takes tees us up for the final step, adding a
`lightning-types` dependency to `lightning-invoice` and using it
for imports rather than the `lightning` crate.

Use `check_added_monitors` test utility in invoice utils tests

In a coming commit, the `lightning-invoice::utils` module will move
to the `lightning` crate, causing its tests to be included in the
global lockorder tests done in that crate. This should be fine,
except that the `lightning-invoice::utils` module currently holds
the `added_monitors` lock too long causing lockorder violations.

Instead, this commit replaces the legacy monitors-added test with
the `check_added_monitors` test utility.

Move `UntrustedString` and `PrintableString` to `lightning-types`

`lightning-invoice` currently has a dependency on the entire
`lightning` crate just because it wants to use some of the useful
types from it. This is obviously backwards and leads to some
awkwardness like the BOLT 11 invoice signing API in the `lightning`
crate taking a `[u5]` rather than a `Bolt11Invoice`.

This takes one more step, moving the `UntrustedString` and
`PrintableString` types to `lightning-types`.

Move `Features` into `lightning-types`

`lightning-invoice` currently has a dependency on the entire
`lightning` crate just because it wants to use some of the useful
types from it. This is obviously backwards and leads to some
awkwardness like the BOLT 11 invoice signing API in the `lightning`
crate taking a `[u5]` rather than a `Bolt11Invoice`.

This takes one more step, moving the `Features` types from
`lightning` to `lightning-types`.

Replace usages of `Features::is_subset` and remove it

It turns out all the places we use `Features::is_subset` we could
as well be using `Features::requires_unknown_bits_from`. Further,
in the next commit `Features` will move to a different crate so any
methods which the `lightning` crate uses will need to be public. As
the `is_subset` API is prety confusing (it doesn't consider
optional/required bits, only whether the bits themselves are
strictly a subset) it'd be nice to not have to expose it, which is
enabled here.

Move `Rout{ingFees,eHint{,Hop}}` to `lightning-types`

`lightning-invoice` currently has a dependency on the entire
`lightning` crate just because it wants to use some of the useful
types from it. This is obviously backwards and leads to some
awkwardness like the BOLT 11 invoice signing API in the `lightning`
crate taking a `[u5]` rather than a `Bolt11Invoice`.

This takes one more step, moving the routing types
`lightning-invoice` uses into `lightning-types`.

Move `Payment{Hash,Preimage,Secret}` into a new crate

`lightning-invoice` currently has a dependency on the entire
`lightning` crate just because it wants to use some of the useful
types from it. This is obviously backwards and leads to some
awkwardness like the BOLT 11 invoice signing API in the `lightning`
crate taking a `[u5]` rather than a `Bolt11Invoice`.

This is the first step towards fixing that - moving the common
types we need into a new `lightning-types` crate which both can
depend on.

Since we're using a new crate and can't depend on the existing
`lightning` hex utility to implement `Display`, we also take this
opportunity to switch to the new `Display` impl macro in
`hex_conservative`.

Test claimable balance is expected for forwarded/outbound payments

Indicate source of balances

Introduce the `BalanceSource` enum to differentiate between force-close,
coop-close, and HTLCs in `Balance::ClaimableAwaitingConfirmations`.

Explain how rounded millisat values are included in overall balance

Test rounded msat balances

Include rounded msat balances in `Balance::ClaimableOnChannelClose`

If we're gonna push users towards using `Balance` to determine
their current balances, we really need to provide more information,
including msat balances.

Here we add rounded-out msat balances to the pre-close balance
information

Add tx fee information to `Balance::ClaimableOnChannelClose`

`Balance::ClaimableOnChannelClose` excludes the commitment
transaction fee, which makes it hard to use for current balance
calculation. Here we add it, setting the value to zero for inbound
channels (i.e. ones for which we don't pay the fee).

Move commitment tx fee calculation helpers to `chan_utils`

These don't really belong in `channel` as they're now used in other
parts of the codebase.

Drop `chan_utils` self-import

There's no reason to `use` a module within that module to refer to
that module...

Include an `outbound_payment` flag in `MaybeTimeoutClaimableHTLC`

When the user is fetching their current balances after forwarding a
payment (before it clears), they'll see a
`MaybePreimageClaimableHTLC` and a `MaybeTimeoutClaimableHTLC` but
if they sum up their balance using
`Balance::claimable_amount_satoshis` neither will be included.

Obviously, exactly one of the two balances should be included - one
of the two resolutions should happen in our favor. This causes our
visible balance to fluctuate up and down by the full value of any
HTLCs we're in the middle of forwarding, which is incredibly
confusing to see. If we want to stop the fluctuations, we need to
pick one of the two balances to include. The obvious candidate is
`MaybeTimeoutClaimableHTLC` as it is the lower of the two, and
represents our balance without the fee we'd receive from the
forward.

Sadly, if we always include it, we'll end up also including any
HTLCs which we've sent but which haven't yet been claimed by their
recipient, which is the wrong behavior.

Luckily, we have access to the `Option<HTLCSource>` while walking
HTLCs, which allows us to add an `outbound_payment` flag to
`MaybeTimeoutClaimableHTLC`. This allows us to only include
forwarded payments in `claimable_amount_satoshis`.

Sadly, even with this in place our balance still fluctuates by the
changes in the commitment transaction fees we have to pay during
forwarding, but addressing that is left for later.

Upgrade all github actions to `v4` variants

Fix misc `shellcheck` complaints

Have `shellcheck` check all scripts in `contrib`

Have `shellcheck` check all scripts in `ci`

Drop `electrsd` autodownload feature for good

... which requires a bunch of unnecessary dev dependencies, e.g., `zip`.

Instead we lean on the `download_bitcoind_electrs.sh` script also for
local testing.

Move CI downloading `bitcoind`/`electrsd` to dedicated shell script

... allowing it to be sourced locally before running
`lightning-transaction-sync` tests.

Merge pull request #3210 from tcharding/07-31-rm-hex-dep

Remove explicit dependency on hex-conservative

Merge pull request #3236 from TheBlueMatt/2024-08-unclonable-graph

Stop relying on a `Clone`able `NetworkGraph` ref in `DefaultRouter`

Stop relying on a `Clone`able `NetworkGraph` ref in `DefaultRouter`

While there's not really much harm in requiring a `Clone`able
reference (they almost always are), it does make our bindings
struggle a bit as they don't support multi-trait bounds (as it
would require synthesizing a new C trait, which the bindings don't
do automatically). Luckily, there's really no reason for it, and we
can just call the `DefaultMessageRouter` directly when we want to
route a message.

We've carried this patch for a while on the bindings branch, but
there's not a strong reason it can't go upstream.

Merge pull request #3214 from TheBlueMatt/2024-07-chan-by-val

Make `funding_transaction_generated` take a `ChannelId` by value

Use bitcoin::hex instead of bitcoin::hashes::hex

Use the `hex-conservative` crate directly from `bitcoin` instead of from
`hashes`. Although it makes no real difference it is slightly more clear
and more terse.

Remove explicit dependency on hex-conservative

The `hex` crate is re-exported by `rust-bitcoin` so we can get it from
there instead of explicitly depending on it. Doing so reduces the
maintenance burden and helps reduce the likelyhood of getting two
versions in the dependency graph.

Merge pull request #3220 from dunxen/2024-08-config-param-consistency

Set default ChannelHandshakeLimits::min_funding_satoshis to 1000

Set default ChannelHandshakeLimits::min_funding_satoshis to 1000

The original default value of 0 was inconsistent with the minimum requirement
of 1000 satoshis in ChannelHandshakeConfig::their_channel_reserve_proportional_millionths.

Merge pull request #3194 from tnull/2024-07-om-event-notifier

Add `Notifier` to `OnionMessenger`

Merge pull request #3215 from tnull/2024-08-protect-against-merkle-leaf-node-weakness

tx-sync: Protect against Core's Merkle leaf node weakness

Protect against Core's Merkle leaf node weakness

Bitcoin Core's Merkle tree implementation has no way to discern between
internal and leaf node entries. As a consequence it is susceptible to an
attacker injecting additional transactions by crafting 64-byte
transactions matching an inner Merkle node's hash (see
https://web.archive.org/web/20240329003521/https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/).

To protect against this (highly unlikely attack vector), we check that
the transaction isn't 64 bytes in length, and skip it otherwise.

Merge pull request #3230 from TheBlueMatt/2024-08-old-doc-tweaks

Minor doc tweaks to `MonitorHolder`

Add `Notifier` to `OnionMessenger`

Merge pull request #3231 from tcharding/08-08-rm-blockdata

Stop using `blockdata` module

Merge pull request #3232 from cooltexture1/fix-#3209

Small fix for #3209

Fix #3209

There was a issue with the ci/check-compiles.sh.
It would return a warning due to links not being enclosed in <>.
Fixed the issue by enclosing the links.

Run contrib/run-rustfmt.sh

No other changes other than those introduced by the script.

Do not use bitcoin::blockdata

The `rust-bitcoin` project is working towards making the public API
separate from the directory structure; eventually the
`bitcoin::blockdata` will go away, to make maintenance easier here stop
using the `blockdata` module.

Do not run the formatter, so as to make review easier. This patch was
created mechanically using:

search-and-replace bitcoin::blockdata bitcoin

and having defined

```bash
search-and-replace () {
        if (($# != 2))
        then
                echo "Usage: $0 <this> <that>"
                return
        fi
        local this="$1"
        local that="$2"
        for file in $(git grep -l "$this")
        do
                perl -pi -e "s/$this/$that/g" "$file"
        done
}
```

Minor doc tweaks to `MonitorHolder`

036c31c9d0b6a243fa33aa5f8d5148d2ca065617 introduced some minor doc
changes but failed to imrpove the docs that is was changing fully
which this does. Suggested by @tnull in review.

Merge pull request #3226 from TheBlueMatt/2024-08-rustfmt-contrib

Add a script to automatically `rustfmt` all required files

Force locale in `rustfmt` shell scripts that rely on sort order

Merge pull request #3219 from dunxen/2024-08-PR2989-followups

Fix remaining feedback and other nits for 2989

Merge pull request #3225 from TheBlueMatt/2024-08-3019-followups

Clean up `CommonOpenChannelFields` docs slightly

Merge pull request #3224 from TheBlueMatt/2024-08-deprecate-send_payment

Mark ChannelManager::send_payment_with_route as deprecated and take `Route` by value

Add a script to automatically `rustfmt` all required files

As we now require `rustfmt` pass on a subset of our files, its
helpful to have a script which will automatically format any
required files so that contributors don't need to think too hard
about it.

Clean up `CommonOpenChannelFields` docs slightly

Merge pull request #3019 from benthecarman/is-public

Add more information to OpenChannelRequest Event

Merge pull request #3202 from jkczyz/2024-07-blinded-path-auth-follow-up

Follow-ups to #3139

Make `funding_transaction_generated` take a `ChannelId` by value

`ChannelId` is just a 32-byte array, so there's not a lot of value
in passing it by reference to `funding_transaction_generated`,
which we fix here.

This is also nice for bindings as languages like Java can better
analyze whether the `ChannelManager` ends up with a reference to
the `ChannelId`.

Make `send_payment_with_route` take `Route` by value

Now that `ChannelManager::send_payment_with_route` is deprecated,
we don't care too much about making it as effecient as possible, so
there's not much cost to making it take `Route` by value. This
avoids bindings being unsure if the by-reference `Route` passed
needs to outlive the `ChannelManager` itself or if it only needs to
outlive the method call, creating some call overhead by forcing a
`Route::clone`, but avoiding a memory leak.

Mark `ChannelManager::send_payment_with_route` as deprecated

We probably should have done this long ago a release or two after
adding `send_payment`, but we didn't and the second best time is
now.

`send_payment_with_route` has particularly hard to use retry
semantics that make it unsuitable for real use. Once we get the
last of our users off of it, we'll want to remove it (or at least
mark it test-only), but we should start by deprecating it.

Fix remaining feedback and other nits for 2989

Merge pull request #3216 from tnull/2024-08-pin-tokio-in-ci

Pin `tokio` in CI to fix MSRV

Pin `tokio` in CI to fix MSRV

The recently released `tokio` 1.39 bumped their MSRV to rustc 1.70.
Here, we pin the `tokio` version to 1.38 for users that require to
maintain our MSRV of rustc 1.63.

Replace use of OffersContext::Unknown with None

Now that ChannelManager uses a known OffersContext when creating blinded
paths, OffersContext::Unknown is no longer needed. Remove it and update
OffersMessageHandler to us an Option, which is more idiomatic for
signifying whether a message was delivered with or without an
OffersContext.

Include payment hash in Bolt12Invoice reply path

Instead of using OffersContext::Unknown for the Bolt12Invoice reply path
use OffersContext::InboundPayment to include the payment hash.
OffersContext::Unknown will be removed in another commit.

Include payment hash when logging invoice handling

Include payment hash when logging InvoiceError

By including the payment hash from the invoice in an onion message's
reply path, it can be used when logging errors as additional context.

Use BlindedPath::new_for_payment in fuzz tests

When creating a Bolt12Invoice in fuzz tests, use
BlindedPath::new_for_payment instead of BlindedPath::new_for_message.
This way PaymentContext is used instead of MessageContext, as is more
realistic though should not affect the test. This allows us to remove
OffersContext::Unknown.

Use different iv_bytes for blinded path metadata

Best practice is to use different IV bytes for different contexts.
Update Offer and Refund metadata computation to use different IV bytes
when the metadata is included in a blinded path. For invoice requests,
the metatdata will always be in the blinded path, so it remains the
same.

Delay adding iv_bytes to MetadataMaterial::hmac

In an upcoming commit, the iv_bytes used in MetadataMaterial will vary
depending on when whether a blinded path is included in the
corresponding message. Delay adding into MetadataMaterial::hmac as
otherwise the HmacEngine would need to be re-initialized using an
ExpandedKey, which won't be readily available.

Result from Bolt12Invoice::verify_using_payer_data

Use a Result return type instead of a bool when verifying a
Bolt12Invoice. This way ignoring the result will produce a compiler
warning.

Bolt12Invoice::is_for_refund_without_paths tests

Merge pull request #3189 from tnull/2024-07-rustfmt-lightning-net-tokio

 `rustfmt`: Run on `lightning-net-tokio`

Merge pull request #3171 from jkczyz/2024-07-propagate-error

Include routing failures in `Bolt12PaymentError`

Add more information to OpenChannelRequest Event

Merge pull request #3203 from lexe-app/pr/description-as-inner

lightning-invoice: Add `Description::as_inner`

lightning-invoice: Add `Description::as_inner`

Merge pull request #3196 from TheBlueMatt/2024-07-monitor-ordering

Ensure `ChannelMonitorUpdate`s are ordered with full monitor writes