973636bd2a 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`
Move the handling of ChannelMonitorUpdateStatus::UnrecoverableError to
the point of error to avoid needing an unwrap later when re-wrapping the
logger.
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.
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.
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.
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.
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.
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.
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.
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.
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.
