Consistently pass `DefaultRouter::new` `Default` scoring parameters

In 26c1639ab69d6780c97a118f09e42cb42304088a (and later in
50c55dcf32466e3ccf17acea50697fc664950deb and
fb693ecbf81be0146a81cc7fd95342c403eacaa9) we switched to using
`Default::default()` to initialize `()` for scoring parameters in
tests. One `()`s slipped back in recently, which we replace here.

Merge pull request #3255 from TheBlueMatt/2024-08-124-beta

Bump version numbers to 0.0.124-beta/invoice 0.32-beta

Merge pull request #3253 from TheBlueMatt/2024-08-new-types-export

Re-export `lightning_types` in top-level `lightning` modules

Bump version numbers to 0.0.124-beta/invoice 0.32-beta

Merge pull request #3245 from valentinewallace/2024-07-blinded-pay-path-refactor

Move `BlindedPayInfo` into `BlindedPaymentPath`

Test blinded PaymentParameter round trip serialization.

Move BlindedPayInfo into blinded_path::payment module.

Move BlindedPayInfo into BlindedPaymentPath.

Also removes the implementation of Writeable for BlindedPaymentPath, to ensure
callsites are explicit about what they're writing.

Merge pull request #3204 from valentinewallace/2024-07-rb-test-vectors

Implement route blinding test vectors

Merge pull request #3188 from TheBlueMatt/2023-12-cache-scoring-points

Better Encapsulate Scoring and Cache Point Count

Merge pull request #3249 from TheBlueMatt/2024-08-feature-cleanup-1

bitcoin 0.32 upgrade followups

Merge pull request #3222 from tnull/2024-08-rustfmt-lightning-persister

`rustfmt`: Run on `lightning-persister`

Avoid && in public API for onion peeling/decoding.

No reason to take a reference to a Deref.

Implement route blinding spec test vectors.

Fix blinded hop feature serialization.

We were writing a length redundantly...

Support next_blinding_override in blinded payment paths.

This allow us to forward blinded payments where the blinded path that we are
forwarding within was concatenated to another blinded path that starts at the
next hop.

Also allows constructing blinded paths using this override.

Remove the `std` feature implications from the `lightning` crate

Now that we don't have to have everything in our entire ecosystem
use the same `std`/`no-std` feature combinations we should start by
untangling our own features a bit.

This takes one last step, removing the implications of the `std`
feature from the `lightning` crate.

Drop the `_test_vectors` feature in favor of a `cfg` flag

This exists just for tests, so there's no reason for it to be
publicly visible.

Somewhat clean up `ci-tests.sh` and sort by `RUSTFLAGS`

Drop the `no-std` feature from `lightning-rapid-gossip-sync`

Now that we don't have to have everything in our entire ecosystem
use the same `std`/`no-std` feature combinations we should start by
untangling our own features a bit.

This takes another step by removing the `no-std` feature entirely
from the `lightning-rapid-gossip-sync` crate and removing all
feature implications on dependencies from the remaining `std`
feature.

Drop the `no-std` feature from `lightning-invoice`

Now that we don't have to have everything in our entire ecosystem
use the same `std`/`no-std` feature combinations we should start by
untangling our own features a bit.

This takes another step by removing the `no-std` feature entirely
from the `lightning-invoice` crate and removing all feature
implications on dependencies from the remaining `std` feature.

Drop the `no-std` feature from BP and drop feature implications

Now that we don't have to have everything in our entire ecosystem
use the same `std`/`no-std` feature combinations we should start by
untangling our own features a bit.

This takes the first step by removing the `no-std` feature entirely
from the `lightning-background-processor` crate and removing most
feature implications on dependencies from the remaining `std`
feature.

It also addresses a CI oversight where we were not testing
`lightning-background-processor` without the `std` feature in CI at
all.

Ensure we always pass a `path` for in-workspace dependencies

In order to ensure our crates depend on the workspace copies of
each other in test builds we need to override the crates.io
dependency with a local `path`.

We can do this in one of two ways - either specify the `path` in
the dependency listing in each crate's `Cargo.toml` or use the
workspace `Cargo.toml` to `patch` all dependencies. The first is
tedious while the second lets us have it all in one place. However,
the second option does break `cargo *` in individual crate
directories (forcing the use of `cargo -p crate *` instead) and
makes it rather difficult to depend on local versions of workspace
crates.

Thus, here we drop the `patch.crates-io` from our top-level
`Cargo.toml` entirely.

Still, we do update the `ci/ci-tests.sh` script here to use
`cargo -p crate` instead of switching to each crate's directory as
it allows `cargo` to use a shared `target` and may speed up tests.

Optimize `BufReader` somewhat for the only used case

`rust-bitcoin` doesn't ever actually *use* its `BufRead`
requirement when deserializing objects, and forcing it is somewhat
inefficient, so we optimize the only (actual) case here by passing
reads straight through to the backing stream.

Fix bug in `BufReader::fill_buf` when reaching EOF

When we reach EOF we may return a full buffer when we should return
an empty one.

Merge pull request #3240 from tnull/2024-08-add-ci-flag-for-bitcoind

Disallow skipping tx-sync tests in CI

Re-export `lightning_types` in top-level `lightning` modules

Since we now have many types in one place, it makes sense to export
them in that place. Further, doing so finally somewhat starts to
reduce our `lightning::ln` module size, which historically is the
dumping ground for everything when most things really should be
top-level modules in `lightning`.

Here we take a step in the right direction by exporting
`lightning_types` as `lightning::types` and encouraging users to
use those paths directly rather than the ones in `lightning::ln`.

Tweak alignment and memory order in the `ProbabilisticScorer`

During routing, the majority of our time is spent in the scorer.
Given the scorer isn't actually doing all that much computation,
this means we're quite sensitive to memory latency. Thus, the cache
lines our data sits on is incredibly important.

Here, we manually lay out the `ChannelLiquidity` and
`HistoricalLiquidityTracker` structs to ensure that we can do the
non-historical scoring and skip historical scoring for channels
with insufficient data by just looking at the same cache line the
channel's SCID is on.

Sadly, to do the full historical scoring we need to load a second
128-byte cache line pair, but we have some time to get there. We
might consider issuing a preload instruction in the future.

This improves performance a few percent.

Cache the total points tracked in our historical liquidity data

When we go to score a channel using the historical liquidity data,
the first thing we do is step through all the valid bucket
combinations, multiply the min and max bucket, and then add them
together to calculate the total number of points tracked. This
isn't a free operation, and for scorers without much data it
represents a large part of the total time spent scoring during
routefinding.

Thus, here we cache this value, updating it every time the buckets
are updated.

Change the directed history tracker's storage of its direction

Rather than storing the two direction's buckets in
`HistoricalMinMaxBuckets` (renamed
`DirectedHistoricalLiquidityTracker`), we store a single reference
to the `HistoricalLiquidityTracker` as well as the direction bool.

This will allow us in the next commit to reference fields in the
`HistoricalLiquidityTracker` aside from the two directions.

Make the historical bucket data private to `bucketed_history`

In a comming commit we'll cache some additional data in the
historical bucket tracker. In order to do so, here we isolate the
buckets themselves into the `bucketed_history` module, reducing
the possibility of accidentally updating them directly without
updating caches.

Store both min and max historical buckets in one, new, struct

In the coming commits we'll isolate historical bucket logic slightly
further, allowing us to cache some state. This is the first step
towards that, storing the historical liquidity information in a new
`HistoricalLiquidityTracker` rather than in the general
`ChannelLiquidity`.

Format `log_approx.rs` per rustfmt

Move log approximation from `scoring.rs` to its own file

Merge pull request #3242 from jkczyz/2024-08-payment-id-auth-api

Add `PaymentId` authentication to public API

`rustfmt`: Drop `lightning-persister` from exclusion list

`rustfmt`: Run on `lightning-persister`

Add PaymentId authentication to public API

When receiving an InvoiceError message, it should be authenticated
before using it to abandon the payment. Add methods to PaymentId's
public API for constructing and verifying an HMAC for use in
OffersContext::OutboundPayment. This allows other implementations of
OffersMessageHandler to construct the HMAC and authenticate the message.

Merge pull request #3239 from arik-so/bitcoin-0.32.2-upgrade

Bitcoin 0.32.2 upgrade

Fix fuzz warnings.

Version 0.32.2 of `rust-bitcoin` deprecates a number of methods that
are commonly used in this project, most visibly `txid()`, which is
now called `compute_txid()`. This resulted in a lot of warnings, and
this commit is part of a series that seeks to address that.

Fix lightning-transaction sync warnings.

Version 0.32.2 of `rust-bitcoin` deprecates a number of methods that
are commonly used in this project, most visibly `txid()`, which is
now called `compute_txid()`. This resulted in a lot of warnings, and
this commit is part of a series that seeks to address that.

Fix lightning-block-sync warnings.

Version 0.32.2 of `rust-bitcoin` deprecates a number of methods that
are commonly used in this project, most visibly `txid()`, which is
now called `compute_txid()`. This resulted in a lot of warnings, and
this commit is part of a series that seeks to address that.

Fix lightning-background-processor warnings.

Version 0.32.2 of `rust-bitcoin` deprecates a number of methods that
are commonly used in this project, most visibly `txid()`, which is
now called `compute_txid()`. This resulted in a lot of warnings, and
this commit is part of a series that seeks to address that.

Fix lightning warnings.

Version 0.32.2 of `rust-bitcoin` deprecates a number of methods that
are commonly used in this project, most visibly `txid()`, which is
now called `compute_txid()`. This resulted in a lot of warnings, and
this commit is part of a series that seeks to address that.

Suppress Taproot warnings.

Taproot is not yet being actively used, and this commit suppresses
the noisy warning generation.

Remove secp256k1 dependency.

Upgrade rust-bitcoin to 0.32.2.

Merge pull request #3182 from valentinewallace/2024-07-expose-advance-bp

Expose blinded paths' `advance_path_by_one`

Return a Result from verify_payment_id

Reimplement io::Cursor.

The `bitcoin::io` Cursor will miss a bunch of functionality that we were
using that we will reimplement here, most critically `set_position`.

Introduce io module.

The rust-bitcoin upgrade will introduce `bitcoin::io` module, which
will be missing a necessary subset of traits.

To accommodate those traits' future implementations, we move the
`lightning::io` module to its own file, where we will be able to
implement the missing trait subset in the next commit.

Drop Seek and SeekFrom usage.

In lieu of using `Seek` and `SeekFrom`, we will instead rely
exclusively on the `io::Cursor` type.

Simplify Readable mutability.

In anticipation of the rust-bitcoin upgrade, which incorporates its
own `io::Read` implementation, we need to make our usage compatible
with dropping `std::io` and `core2::io`.

Notably, in version 0.32.2, `bitcoin::io`'s `Read` is no longer
implemented for `&mut R where R: Read + ?Sized`, which results in
errors anytime `&mut &mut Readable` is passed instead of
`&mut Readable`.

This commit fixes those instances.

Disallow skipping tx-sync tests in CI

Previously, we'd always skip tx-sync tests if the
`BITCOIND_EXE`/`ELECTRS_EXE` environment variables would be unset. While
this is especially fine for local testing, we still want to enforce
tests failing if somehow the `bitcoind`/`electrs` downloading or caching
in CI stops working. Here, we therefore add a `CI_ENV` variable that
indicates we're indeed running in CI, and only skip if it's unset.

Make advance_path_by_one an associated method.

Tweak phrasing in Blinded{Message,Payment}Path::advance_path_by_one docs.

Move NextMessageHop into blinded_path::message

It's only used for onion messages, not payments.

Make BlindedPath type private.

Users should use the Blinded{Message,Payment}Path types instead.

Reduce visibility of BlindedMessagePath inner path.

Works towards making the inner BlindedPath struct private to the module.

Merge pull request #3241 from TheBlueMatt/2024-08-ret-slice-not-ref-vec

Return slices, rather than `Vec` references, in addresses

Reduce visibility of BlindedPaymentPath inner path.

Works towards making the inner BlindedPath struct private to the module.

Add accessor methods for inner blinded path fields.

Move public_intro_node util into Blinded{Message,Payment}Path

Helps move towards making the BlindedPath struct private.

Move compact blinded path util to message paths only.

It's only used for message paths, so let's move it there to help make the
BlindedPath struct private.

Expose blinded paths' advance_path_by_one methods.

Useful for LDK users that are using the onion messages module, like LNDK.

Add BlindedMessagePath type to disambiguate from blinded payment paths.

Add BlindedPaymentPath type, to disambiguate from message paths.

Next up, we'll add a BlindedMessagePath type so the API is clear which type of
path is expected in each context.

Return slices, rather than `Vec` references, in addresses

Its a bit strange to return a reference to a `Vec` in Rust, when a
slice is really intended as the way to do so. Worse, the bindings
don't know how to map a reference to a `Vec` (but do have code to
map a slice of `Clone`able objects).

Here, we move `NodeAnnouncementInfo::addresses` to return a slice,
though to do so we have to adapt the `WithoutLength` `Writeable`
impl to support slices as well.

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`.