Pre-calculate heap element scores (retaining RouteGraphNode size)

`RouteGraphNode` currently recalculates scores in its `Ord`
implementation, wasting time while sorting the main Dijkstra's
heap.

Further, some time ago, when implementing the `htlc_maximum_msat`
amount reduction while walking the graph, we added
`PathBuildingHop::was_processed`, looking up the source node in
`dist` each time we pop'ed an element off of the binary heap.
As a result, we now have a reference to our `PathBuildingHop` when
processing a best-node's channels, leading to several fields in
`RouteGraphNode` being entirely redundant.

Here we drop those fields, but add a pre-calculated score field,
as well as force a suboptimal `RouteGraphNode` layout, retaining
its existing 64 byte size.

Without the suboptimal layout, performance is very mixed, but with
it performance is mostly improved, by around 10% in most tests.

Reorder `PathBuildingHop` fields somewhat

Given `PathBuildingHop` is now an even multiple of cache lines, we
can pick which fields "fall off" the cache line we have visible
when dealing with hops, which we do here.

Make `find_route`'s `dist` map elements fit in 128 bytes

We'd previously aggressively cached elements in the
`PathBuildingHop` struct (and its sub-structs), which resulted in a
rather bloated size. This implied cache misses as we read from and
write to multiple cache lines during processing of a single
channel.

Here, we reduce caching in `DirectedChannelInfo`, fitting the
`(NodeId, PathBuildingHop)` tuple in exactly 128 bytes. While this
should fit in a single cache line, it sadly does not generally lie
in only two lines, as glibc returns large buffers from `malloc`
which are very well aligned, plus 16 bytes (for its own allocation
tracking). Thus, we try to avoid reading from the last 16 bytes of
a `PathBuildingHop`, but luckily that isn't super hard.

Note that here we make accessing
`DirectedChannelInfo::effective_capacity` somewhat slower, but
that's okay as its only ever done once per `DirectedChannelInfo`
anyway.

While our routing benchmarks are quite noisy, this appears to
result in between a 5% and 15% performance improvement in the
probabilistic scoring benchmarks.

Make `CandidateRouteHop::PrivateHop::target_node_id` a reference

This avoids bloating `CandidateRouteHop` with a full 33-byte
node_id (and avoids repeated public key serialization when we do
multiple pathfinding passes).

Simplify and make scoring calls in `TestRouter` more complete

`TestRouter` tries to make scoring calls that mimic what an actual
router would do, but the changes in f0ecc3ec73dcdb9303b1bd5ac687a36
failed to make scoring calls for private hints or if we take a
public hop for the last hop.

This fixes those regressions, though no tests currently depend on
this behavior.

Make `CandidateRouteHop` method docs somewhat more descriptive

Fix indentation in `router.rs` broken in a1d15ac1926f70aa5ab4f6686f

Rename `CandidateRouteHop::FirstHop::node_id` and make it a ref

Rather than calling `CandidateRouteHop::FirstHop::node_id` just
`node_id`, we should call it `payer_node_id` to provide more
context.

We also take this opportunity to make it a reference, avoiding
bloating `CandidateRouteHop`.

`#[inline]` `CandidateRouteHop` accessors

These are used in the performance-critical routing and scoring
operations, which may happen outside of our crate. Thus, we really
need to allow downstream crates to inline these accessors into
their code, which we do here.

Fix new unused warnings in `scoring.rs`

Privatise `CandidateRouteHop::short_channel_id` as its a footgun

Short channel "ID"s are not globally unique when they come from a
BOLT 11 route hint or a first hop (which can be an outbound SCID
alias). In those cases, its rather confusing that we have a
`short_channel_id` method which mixes them all together, and even
more confusing that we have a `CandidateHopId` which is not, in
fact returning a unique identifier.

In our routing logic this is mostly fine - the cost of a collision
isn't super high and we should still do just fine finding a route,
however the same can't be true for downstream users, as they may or
may not rely on the apparent guarantees.

Thus, here, we privatise the SCID and id accessors.

Fix and re-enable the `remembers_historical_failures` test

f0ecc3ec73dcdb9303b1bd5ac687a361decce2dd introduced a regression in
the `remembers_historical_failures` test, and disabled it by simply
removing the `#[test]` annotation. This fixes the test and marks it
as a test again.

Rename `DirectedChannelInfo::outbound` to `from_node_one`

...to give a bit more readability on accessing sites.

Rewrite docs in `CandidateRouteHop` to be somewhat more descriptive

Merge pull request #2551 from jbesraa/expose-CandidateRouteHop-to-channel_penalty_msat

Add CandidateRouteHop to channel_penalty_msat inputs

Merge pull request #2735 from valentinewallace/2023-11-skimmed-fee-ser

Fix skimmed fee serialization in `Channel`

Merge pull request #2773 from johncantrell97/apeermanager-lbs

simplify GossipVerifier types using APeerManager

simplify GossipVerifier types using APeerManager

Remove `node_id` from `PathBuildingHop`

  We remove `node_id` from `PathBuildingHop`
  as we can rely `CandidateRouteHop::target`
  instead.

Use `CandidateRouteHop` as input for `channel_penalty_msat`

  We remove `source`, `target` and `scid` from
  `channel_penalty_msat` inputs to consume them from
  `candidate` of type `CandidateRouteHop`

Change `CandidateRouteHop` functions visbility

  Change `short_channel_id`, `cltv_expiry_delta`
  `fees` and `htlc_minimum_msat` under `CandidateRouteHop` visibility
  to public and add documentation.

Add `source` and `target` fn's to `CandidateRouteHop`

    We add `CandidateRouteHop::source` and
    `CandidateRouteHop::source` functions to point
    to current and next hops in route respectively.
    As we have now `source` and `target`
    available in `CandidateRouteHop` we also
    remove `CandidateRouteHop::id` inputs
    so now they are consumed from `self.target`
    and `self.source` functions.
    In the `add_entry` macro we also remove `source`
    and `target` arguments in favor of `candidate`
    of type `CandidateRouteHop` that holds the
    needed info.

Add `source` and `target` to `DirectedChannelInfo`

  `DirectedChannelInfo::source` return the `node_id`
  of the forwarding hop.
  `DirectedChannelInfo::target` return the `node_id`
  of the destination hop.

Add `outbound` flag to `DirectedChannelInfo`

  If `outband` flag is set to true then `ChannelInfo::node_one`
  is forwarding a payment to target `ChannelInfo::node_two`.
  If `outband` flag is set to false then `ChannelInfo::node_two`
  is forwarding a payment to target `ChannelInfo::node_one`.

Merge pull request #2764 from TheBlueMatt/2023-11-chacha-cleanup

Trivial ChaCha cleanups

Merge pull request #2642 from Sharmalm/2346

 logging every sent receive onion message

Fix skimmed fee ser in Channel

Previously, if some holding cell HTLCs have skimmed fees present and some
don't, we would fail to deserialize a Channel. See added test coverage.

Merge pull request #2753 from TheBlueMatt/2023-11-inbound-preimages

Provide inbound HTLC preimages to the `EcdsaChannelSigner`

Merge pull request #2771 from tnull/2023-12-log-details-for-ignored-first-hop

Log additional details when ignoring first hops

Provide inbound HTLC preimages to the `EcdsaChannelSigner`

The VLS signer has a desire to see preimages for resolved forwarded
HTLCs when they are first claimed by us, even if that claim was for
the inbound edge (where claiming strictly increases our balance).

Luckily, providing that information is rather trivial, which we do
here.

Fixes #2356

Merge pull request #2769 from TheBlueMatt/2023-12-2314-cleanups-3

Post-#2314 Cleanups #3

Log additional details when ignoring first hops

Users are often confused when we fail to find a route due to some
requirements on the first hop are not being met. While we now take note
and log such candidates, we still previously required users to check
additional details to figure out why exactly the router refused to route
over a particular first hop.

Here, we add additional TRACE logging, in particular for
`ChannelDetails::next_outbound_htlc_limit_msat` and
`ChannelDetails::next_outbound_htlc_minimum_msat` when they are
relevant.

Merge pull request #2768 from benthecarman/preimage-helper

Add helper function for getting preimage from PaymentPurpose

Merge pull request #2766 from TheBlueMatt/2023-12-2314-cleanups-2

Marginally optimize test logging

Doc that `Record::node_id` may be missing even with `channel_id`

There are various place where we log something related to a channel
but fail to fill in the channel's counterparty information. This is
somewhat surprising, given channel counterparty information is
always known, but simply is sometimes not readily accessible to LDK
when a log is printed.

Set log metadata in a few additional locations in `channelmanager`

Log next-hop metadata when forwarding or failing to forward HTLC

Include next-hop counterparty node id in log metadata when sending

Add missing counterparty node id metadata to logs in HTLC decoding

Add helper function for getting preimage from PaymentPurpose

Include counterparty node id and channel id in shutdown log

This avoids an important shutdown log being about a channel but not
having the channel metadata.

Add missing `unwrap` in `reload_tests.rs`

Marginally optimize test logging

973636bd2ab2ba35fb8b9703f1d5d0e72f069cdc introduced a new `HashMap`
in the `TestLogger` but then did lookups by iterating the entire
map. This fixes that, and also takes this opportunity to stop
allocating new `String`s for the module to store each log entry in
the `TestLogger`

logging every sent and receive onion message

Logs every sent + receive for P2P messages
solves #2346

Merge pull request #2314 from henghonglee/issue-2292

Add peer_id and channel_id explicitly to log records

Refactor ChainMonitor::update_channel error case

Move the handling of ChannelMonitorUpdateStatus::UnrecoverableError to
the point of error to avoid needing an unwrap later when re-wrapping the
logger.

Remove unused handle_error macro rule

Use wrapper to add context to logging

Using a decorator pattern, add peer_id and channel_id to Record
stored on Logger.

Add WithChannelMonitor

Add WithChannelContext

Add WithChannelDetails

Add WithContext and Tests

Add semantics to logger::Records

Include optional peer and channel ids to logger::Record. This will be
used by wrappers around Logger in order to provide more context (e.g.,
the peer that sent a message, the channel an operation is pertaining to,
etc.). Implementations of Logger can include this as metadata to aid in
searching logs.

Pass Record by value to Logger

Instead of passing a reference to a Record, pass the Logger an owned
Record so that it can be decorated with semantic context.

Merge pull request #2540 from valentinewallace/2023-08-blinded-errors

Route blinding: support forwarding as the intro node

Add inline suggestion tags to ChaCha20 SIMD wrappers

These are obviously super hot, and while LLVM shouldn't be
braindead here you never know, so we might as well `#[inline]`.

Drop unnecessary SIMD subtraction in ChaCha20 `round`

While its all constant arithmetic to calculate the shift, which
LLVM likely optimizes out for us, there's no reason to do it four
times, which just makes the code harder to read.

Test blinding point serialization in Channel.

Add release note for blinded HTLC backwards compat.

Test intro node failing blinded intercept HTLC.

Test intro node blinded HTLC failing in process_pending_htlc_fwds.

Correctly fail back downstream-failed blinded HTLCs as intro

Correctly fail back blinded inbound fwd HTLCs when adding to a Channel

As the intro node.

Extract blinded route param creation into test util

Correctly fail back on outbound channel check for blinded HTLC

Forwarding intro nodes should always fail with 0x8000|0x4000|24.

Test blinded forwarding payload encoded as receive error case

Test blinded forward failure to calculate outbound cltv expiry

Intro node failure only.

Remove now-unused Readable impl for ReceiveTlvs

Support forwarding blinded HTLCs as intro node.

Error handling will be completed in upcoming commits.

Parse blinded forward-as-intro onion payloads

Previously, we only parsed blinded receive payloads.

Set update_add blinding point on HTLC forward

Used by the next hop to decode their blinded onion payload.

Parameterize Channel's htlc forward method by outbound blinding point

Used in the next commit to set the update_add blinding point on HTLC forward.

Set HTLCPreviousHopData::blinded on intro node forward.

Useful so we know to fail back blinded HTLCs where we are the intro node with
the invalid_onion_blinding error per BOLT 4.

We don't set this field for blinded received HTLCs because we don't support
receiving to multi-hop blinded paths yet, and there's no point in setting it
for HTLCs received to 1-hop blinded paths because per the spec they should fail
back using an unblinded error code.

Persist whether an HTLC is blinded in HTLCPreviousHopData.

Useful so we know to fail blinded intro node HTLCs back with an
invalid_onion_blinding error per BOLT 4.

Another variant will be added to the new Blinded enum when we support
receiving/forwarding as a non-intro node.

Store whether a forwarded HTLC is blinded in PendingHTLCRouting

We need to store the inbound blinding point in PendingHTLCRouting in order to
calculate the outbound blinding point.

The new BlindedForward struct will be augmented when we add support for
forwarding as a non-intro node.

Persist outbound blinding points in Channel

A blinding point is provided in update_add_htlc messages if we are relaying or
receiving a payment within a blinded path, to decrypt the onion routing packet
and the recipient-provided encrypted payload within. Will be used in upcoming
commits.

Parse blinded onion errors in tests only.

So we can make sure they're encoded properly.

onion_utils: extract decrypting faiure packet into method

Will be used in the next commit to parse onion errors from blinded paths in
tests only.

Parse blinding point in UpdateAddHTLC

A blinding point is provided in update_add_htlc messages if we are relaying or
receiving a payment within a blinded path, to decrypt the onion routing packet
and the recipient-provided encrypted payload within. Will be used in upcoming
commits.

Merge pull request #2739 from Evanfeenstra/channelmanager-utils

move static channelmanager functions into their own file

Merge pull request #2721 from TheBlueMatt/2023-11-log-forward-peer

Handle missing case in reestablish local commitment number checks

Merge pull request #2755 from arik-so/arik/taproot-2023-11-followup-2512

Followups to 2512

Remove unused Taproot import.

Move validate_counterparty_revocation to ChannelSigner.

Remove superfluous commitment_number parameter.

Gate Taproot-related todos behind cfg flag.

move static channelmanager functions into their own file

Merge pull request #2512 from arik-so/taproot/2023-08-taproot-signer-variant

Taproot signer variant

Merge pull request #2749 from TheBlueMatt/2023-11-2744-followups

Add `channel_keys_id` to `SpendableOutputDescriptor::StaticOutput`

Move ECDSA-specific signers into ecdsa.rs

To separate out the logic in the `sign` module, which will start to be
convoluted with multiple signer types, we're splitting out each signer
type into its own submodule, following the taproot.rs example from a
previous commit.

Reparametrize ChannelSignerType by SignerProvider.

ChannelSignerType is an enum that contains variants of all currently
supported signer types. Given that those signer types are enumerated
as associated types in multiple places, it is prudent to denote one
type as the authority on signer types.

SignerProvider seemed like the best option. Thus, instead of
ChannelSignerType declaring the associated types itself, it simply
uses their definitions from SignerProvider.

Add TaprootSigner variant to SignerProvider.

Previously, SignerProvider was not laid out to support multiple signer
types. However, with the distinction between ECDSA and Taproot signers,
we now need to account for SignerProviders needing to support both.

This approach does mean that if ever we introduced another signer type
in the future, all implementers of SignerProvider would need to add it
as an associated type, and would also need to write a set of dummy
implementations for any Signer trait they do not wish to support.

For the time being, the TaprootSigner associated type is cfg-gated.

Introduce TaprootSigner trait.

For Taproot support, we need to define an alternative trait to
EcdsaChannelSigner. This trait will be implemented by all signers
that wish to support Taproot channels.

Rename SignerProvider's Signer to EcdsaSigner.

Handle missing case in reestablish local commitment number checks

If we're behind exactly one commitment (which we've revoked), we'd
previously force-close the channel, guaranteeing we'll lose funds
as the counterparty has our latest local commitment state's
revocation secret.

While this shouldn't happen because users should never lose data,
sometimes issues happen, and we should ensure we always panic.

Further, `test_data_loss_protect` is updated to test this case.

Clean up error messages and conditionals in reestablish handling

When we reestablish there are generally always 4 conditions for
both local and remote commitment transactions:
 * we're stale and have possibly lost data
 * we're ahead and the peer has lost data
 * we're caught up
 * we're nearly caught up and need to retransmit one update.

In especially the local commitment case we had a mess of different
comparisons, which is improved here. Further, the error messages
are clarified and include more information.

Add `channel_keys_id` to `SpendableOutputDescriptor::StaticOutput`

In 7f0fd868ad4e8072440f1eb79e78894de1629157, `channel_keys_id` was
added as an argument to `SignerProvider::get_destination_script`,
allowing implementors to generate a new script for each channel.

This is great, however users then have no way to re-derive the
corresponding private key when they ultimately receive a
`SpendableOutputDescriptor::StaticOutput`. Instead, they have to
track all the addresses as they derive them separately. In many
cases this is fine, but we should support both deployments, which
we do here by simply including the missing `channel_keys_id` for
the user.

Merge pull request #2744 from rmalonson/destinationscript

Add channel_keys_id as param in get_destination_script to support gen…

Merge pull request #2675 from yellowred/delayed_payment_key_types

Implement struct wrappers for Payment, DelayedPayment, HTLC and Revocation channel keys

Add channel_keys_id as param in get_destination_script

This enables implementers to generate a different destination script for each channel.