Define BOLT 12 invoice features with MPP support

Use explicit WithoutLength for BOLT 12 features

Most BOLT 12 features are used as the value of a TLV record and thus
don't use an explicit length. One exception is the features inside the
blinded payinfo subtype since the TLV record contains a list of them.
However, these features are also used in the BOLT 4 encrypted_data_tlv
TLV stream as a single record, where the length is implicit.

Implement Readable and Writeable for Features wrapped in WithoutLength
such that either serialization can be used where required.

Remove Option from InvoiceRequest::signature

Refunds don't have signatures and now use their own abstraction.
Therefore, signatures can be required in invoice requests as per the
spec.

Correct documentation about Refund::payer_id

The docs incorrectly stated that Refund::payer_id is for signing, where
it is only used for identifying a node if Refund::paths is not present.

Refund parsing tests

Tests for checking refund semantics when parsing invoice_request bytes
as defined by BOLT 12.

Refund building tests

Tests for checking invoice_request message semantics when building a
refund as defined by BOLT 12.

Builder for creating refunds

Add a builder for creating refunds given a payer_id and other required
fields. Other settings are optional and duplicative settings will
override previous settings. Building produces a semantically valid
`invoice_request` message representing the refund, which then may be
communicated out of band (e.g., via QR code).

Refund parsing from bech32 strings

Implement Bech32Encode for Refund, which supports creating and parsing
QR codes for the merchant-pays-user (i.e., offer for money) flow.

Refund encoding and parsing

Define an interface for BOLT 12 refunds (i.e., an `invoice_request`
message without an `offer_node_id`). A refund is more generally an
"offer for money". While it is encoded using the same TLV streams as an
`invoice_request` message, it has different semantics.

Remove Option from OfferContents::signing_pubkey

Refunds (i.e., `invoice_request` without an `offer`) will have its own
contents type, so OfferContents::signing_pubkey can be required.

Check entire TLV stream instead of by field

This causes a compilation error if a new field is added but missed in
the tests.

Add BOLT 12 merkle root test for `invoice_request`

A BOLT 12 test vector uses an `invoice_request` message that has a
currency, which aren't supported, so using OfferBuilder::build_unchecked
is required to avoid a panic.

Invoice request parsing tests

Tests for checking invoice_request message semantics when parsing bytes
as defined by BOLT 12.

Invoice request building tests

Tests for checking invoice_request message semantics when building as
defined by BOLT 12.

Builder for creating invoice requests

Add a builder for creating invoice requests for an offer given a
payer_id. Other settings may be optional depending on the offer and
duplicative settings will override previous settings. Building produces
a semantically valid `invoice_request` message for the offer, which then
can be signed for the payer_id.

Invoice request raw byte encoding and decoding

When reading an offer, an `invoice_request` message is sent over the
wire. Implement Writeable for encoding the message and TryFrom for
decoding it by defining in terms of TLV streams. These streams represent
content for the payer metadata (0), reflected `offer` (1-79),
`invoice_request` (80-159), and signature (240).

Merkle root hash computation

Offers uses a merkle root hash construction for signature calculation
and verification. Add a submodule implementing this so that it can be
used when parsing and signing invoice_request and invoice messages.

Schnorr Signature serialization

BOLT 12 uses Schnorr signatures for signing offers messages, which need
to be serialized.

Invoice request message interface and data format

Define an interface for BOLT 12 `invoice_request` messages. The
underlying format consists of the original bytes and the parsed
contents.

The bytes are later needed when constructing an `invoice` message. This
is because it must mirror all the `offer` and `invoice_request` TLV
records, including unknown ones, which aren't represented in the
contents.

The contents will be used in `invoice` messages to avoid duplication.
Some fields while required in a typical user-pays-merchant flow may not
be necessary in the merchant-pays-user flow (e.g., refund, ATM).

Remove unused mut from OfferBuilder::amount_msats

Seen when removing `#[allow(unused)]` from `offers` module.

Reduce visibility for offer auxiliary types

Merge pull request #1852 from TheBlueMatt/2022-11-accept-bad-but-better-fee-updates

Accept feerate increases even if they aren't high enough for us

Merge pull request #1726 from jkczyz/2022-09-offer-parsing

BOLT 12 offer parsing

Expose the default Quantity::one as pub

Limit TLV stream decoding to type ranges

BOLT 12 messages are limited to a range of TLV record types. Refactor
decode_tlv_stream into a decode_tlv_stream_range macro for limiting
which types are parsed. Requires a SeekReadable trait for rewinding when
a type outside of the range is seen. This allows for composing TLV
streams of different ranges.

Updates offer parsing accordingly and adds a test demonstrating failure
if a type outside of the range is included.

Offer parsing tests

Test semantic errors when parsing offer bytes.

Use SemanticError in OfferBuilder::build

Offer parsing from bech32 strings

Add common bech32 parsing for BOLT 12 messages. The encoding is similar
to bech32 only without a checksum and with support for continuing
messages across multiple parts.

Messages implementing Bech32Encode are parsed into a TLV stream, which
is converted to the desired message content while performing semantic
checks. Checking after conversion allows for more elaborate checks of
data composed of multiple TLV records and for more meaningful error
messages.

The parsed bytes are also saved to allow creating messages with mirrored
data, even if TLV records are unknown.

Merge pull request #1855 from tnull/2022-11-inbound-user-channel-id-randomization-fixup

Inbound `user_channel_id` randomization follow-up

Remove unused import

Mention `user_channel_id` rand. version req.

As it was previously omitted, we clarify here starting from which version users can expect the `user_channel_id` to be randomized for inbound channels.

Also set `user_channel_id` when its overridden

Merge pull request #1826 from TheBlueMatt/2022-10-idempotency-err

Add a separate PaymentSendFailure for idempotency violation

Merge pull request #1853 from TheBlueMatt/2022-11-reload-macro

Replace manual node reloading with a macro/function in tests

Merge pull request #1851 from TheBlueMatt/2022-11-fix-broken-futures-----again

Unset the needs-notify bit in a Notifier when a Future is fetched

Accept feerate increases even if they aren't high enough for us

LND nodes have very broken fee estimators, causing them to suggest
feerates that don't even meet a current mempool minimum feerate
when fees go up over the course of hours. This can cause us to
reject their feerate estimates as they're not high enough, even
though their new feerate is higher than what we had already (which
is the feerate we'll use to broadcast a closing transaction). This
implies we force-close the channel and broadcast something with a
feerate lower than our counterparty was offering.

Here we simply accept such feerates as they are better than what we
had. We really should also close the channel, but only after we
get their signature on the new feerate. That should happen by
checking channel feerates every time we see a new block so is
orthogonal to this code.

Ultimately the fix is anchor outputs plus package-based relay in
Bitcoin Core, however we're still quite some ways from that, so
worth needlessly closing channels for now.

Await `Future::poll` `Complete`d before unsetting notify-required

When we mark a future as complete, if the user is using the
`std::future::Future` impl to get notified, we shouldn't just
assume we have completed the `Future` when we call the `Waker`. A
`Future` may have been `drop`'d at that point (or may not be
`poll`'d again) even though we wake the `Waker`.

Because we now have a `callbacks_made` flag, we can fix this rather
trivially, simply not setting the flag until the `Future` is
`poll`'d `Complete`.

Wipe `Notifier` `FutureState` when returning from a waiter.

When we return from one of the wait functions in `Notifier`, we
should also ensure that the next `Future` doesn't start in the
`complete` state, as we have already notified the user, as far as
we're concerned.

This is technically a regression from the previous commit, but as
it is a logically separate change it is in its own commit.

Unset the needs-notify bit in a Notifier when a Future is fetched

If a `Notifier` gets `notify()`ed and the a `Future` is fetched,
even though the `Future` is marked completed from the start and
the user may pass callbacks which are called, we'll never wipe the
needs-notify bit in the `Notifier`.

The solution is to keep track of the `FutureState` in the returned
`Future` even though its `complete` from the start, adding a new
flag in the `FutureState` which indicates callbacks have been made
and checking that flag when waiting or returning a second `Future`.

Remove excess module

This appears to have been added with the intent of having a sealed
trait, which was never committed.

Move restart-related tests to their own file

Replace manual node reloading with a macro/function in tests

Fixes #1696

Merge pull request #1790 from tnull/2022-10-inbound-user-channel-id-randomization

Randomize `user_channel_id` for inbound channels

Make `user_channel_id` a `u128`

We increase the `user_channel_id` type from `u64` to `u128`. In order to
maintain backwards compatibility, we have to de-/serialize it as two
separate `u64`s in `Event` as well as in the `Channel` itself.

Randomize `user_channel_id` for inbound channels

Previously, all inbound channels defaulted to a `user_channel_id` of 0,
which didn't allow for them being discerned on that basis. Here, we
simply randomize the identifier to fix this and enable the use of
`user_channel_id` as a true identifier for channels (assuming an equally
reasonable value is chosen for outbound channels and given upon
`create_channel()`).

Introduce `init_and_read_tlv_fields` macro

We introduce a new macro that inits and reads tlv fields and DRY up
`impl_writeable_tlv_based` and other macros.

Merge pull request #1845 from TheBlueMatt/2022-11-future-wake-fix

Fix persistence-required futures always completing instantly

Merge pull request #1806 from arik-so/2022-10-background-processor-deparametrization

Remove generic `Signer` parameter where it can be inferred from `KeysInterface`

Fix persistence-required futures always completing instantly

After the first persistence-required `Future` wakeup, we'll always
complete additional futures instantly as we don't clear the
"need wake" bit. Instead, we need to just assume that if a future
was generated (and not immediately drop'd) that its sufficient to
notify the user.

Merge pull request #1413 from ViktorTigerstrom/2022-04-default-to-bolt4-tlv-onions

Drop support for creating BOLT 4 Legacy onion format payloads

Add test for only creating tlv format onions

Remove `OnionHopDataFormat::Legacy`

Update BOLT4 onion test vectors

Merge pull request #1787 from wpaulino/async-event-handler

Handle events asynchronously in the BackgroundProcessor's async variant

Note async versions of event handling within EventsProvider

Drop DecoratingEventHandler in favor of inline closure

Handle events asynchronously in the BackgroundProcessor's async variant

Implement async versions of process_pending_events

Consume events by value in EventHandler's handle_event

Use BaseEventHandler to expose async event handling on InvoicePayer

We introduce a new sealed trait BaseEventHandler that has a blanket
implementation for any T. Since the trait cannot be implemented outside
of the crate, this allow us to expose specific implementations of
InvoicePayer that allow for synchronous and asynchronous event handling.

Apply network graph updates through NetworkUpdate's instead of Event's

Merge pull request #1844 from valentinewallace/2022-11-htlc-interception-refactor-followup

Rename `PendingHTLCInfo` fields to include msat suffix

Merge pull request #1843 from TheBlueMatt/2022-11-fix-bp-exit-docs

Correct async `lightning-background-processor` exit check docs

Remove generic `Signer` parameter where it can be inferred from `KeysInterface`

Merge pull request #1796 from tnull/2022-10-track-confirmation-block-hash

Track confirmation block hash and return via `Confirm::get_relevant_txids`

Rename PendingHTLCInfo fields to include msat suffix

Merge pull request #1842 from jkczyz/2022-11-channel-monitor-docs

Fix outdated `ChannelMonitor` docs

Add a separate PaymentSendFailure for idempotency violation

When a user attempts to send a payment but it fails due to
idempotency key violation, they need to know that this was the
reason as they need to handle the error programmatically
differently from other errors.

Here we simply add a new `PaymentSendFailure` enum variant for
`DuplicatePayment` to allow for that.

Rename `PaymentSendFailure::AllFailedRetrySafe` `...ResendSafe`

It was pointed out that its quite confusing that
`AllFailedRetrySafe` does not allow you to call `retry_payment`,
though the documentation on it does specify this. Instead, we
simply rename it to `AllFailedResendSafe` to indicate that the
action that is safe to take is *resending*, not *retrying*.

Correct async `lightning-background-processor` exit check docs

The check to stop the background processor is true -> break, not
false -> break. This simply updates the docs and leaves the code
as-is.

Merge pull request #1840 from valentinewallace/2022-11-htlc-intercept-prefactor

Pre-refactor for HTLC Interception

Fix outdated ChannelMonitor docs

ChannelMonitor::get_and_clear_pending_events docs references a method
that had been refactored and is no longer accurate.

Merge pull request #1834 from dunxen/2022-11-expose-pending-monitor-updates

Add public method to list pending monitor updates from `ChainMonitor`

Track block hash, return via `get_relevant_txids`

Previously, `Confirm::get_relevant_txids()` only returned a list of
transactions that have to be monitored for reorganization out of the
chain. This interface however required double bookkeeping: while we
internally keep track of the best block, height, etc, it would also
require the user to keep track which transaction was previously
confirmed in which block and to take actions based on any change, e.g,
to reconfirm them when the block would be reorged-out and the
transactions had been reconfirmed in another block.

Here, we track the confirmation block hash internally and return it via
`Confirm::get_relevant_txids()` to the user, which alleviates the
requirement for double bookkeeping: the user can now simply check
whether the given transaction is still confirmed and in the given block,
and take action if not.

We also split `update_claims_view`: Previously it was one, now it's two
methods: `update_claims_view_from_matched_txn` and
`update_claims_view_from_requests`.

Add public method to list pending monitor updates from `ChainMonitor`

Users have requested the feature to list pending monitor updates from
`ChainMonitor` so this adds that.

Merge pull request #1719 from jkczyz/2022-09-offer-encoding

BOLT 12 `offer` encoding and building

Fix scid_utils::is_valid* false positive

cargo bench was able to find an scid of 0 as a valid fake scid

Track incoming amount in PendingHTLCInfo

Used in upcoming commit(s) when we generate the PaymentIntercepted event for
intercepted payments.

Co-authored-by: John Cantrell <johncantrell97@gmail.com>
Co-authored-by: Valentine Wallace <vwallace@protonmail.com>

Delete unnecessary whitespace in process_pending_forwards

Only whitespace diff

Refactor HTLCForwardInfo::AddHTLC for intercept forwards

In upcoming commit(s), we'll want to store intercepted HTLC forwards in
ChannelManager before the user signals that they should be forwarded.  It
wouldn't make sense to store a HTLCForwardInfo as-is because the FailHTLC
variant doesn't make sense, so we refactor out the ::AddHTLC contents into its
own struct for storage.

Co-authored-by: John Cantrell <johncantrell97@gmail.com>
Co-authored-by: Valentine Wallace <vwallace@protonmail.com>

Merge pull request #1833 from johncantrell97/2022-11-rgs-handle-removed-channel

Ignore RGS channel updates for unknown channels

Builder for creating offers

Add a builder for creating offers given a required description and
node_id. Other settings are optional and duplicative settings will
override previous settings for non-Vec fields.

Merge pull request #1837 from tnull/2022-10-fix-meeting-time

Fix LDK Dev Meeting time

Fix LDK Dev Meeting time and typo

ignore updates for unknown channels

Merge pull request #1639 from ViktorTigerstrom/2022-07-move-short-to-chan-info

Move `short_to_chan_info` into standalone lock

Serialization macro for TLV streams

BOLT 12's offer message is encoded as a TLV stream (i.e., a sequence of
TLV records). impl_writeable_tlv_based can't be used because it writes
the overall length of the struct, whereas TLV streams only include the
length of each TLV record. Add a `tlv_stream` macro for defining structs
used in encoding.

TLV records containing a single variable-length type should not encode
the types length in the value since it is redundant. Add a wrapper type
that can be used within a TLV stream to support the correct behavior
during serialization and de-serialization.

Add WithoutLength wrapper

When serializing variable-length types as part of a TLV stream, the
length does not need to be serialized as it is already encoded in TLV
records. Add a WithoutLength wrapper for this encoding. Replace
VecReadWrapper and VecWriteWrapper with this single type to avoid
redundant encoders.

Offer message interface and data format

Define an interface for BOLT 12 `offer` messages. The underlying format
consists of the original bytes and the parsed contents.

The bytes are later needed when constructing an `invoice_request`
message. This is because it must mirror all the `offer` TLV records,
including unknown ones, which aren't represented in the contents.

The contents will be used in `invoice_request` messages to avoid
duplication. Some fields while required in a typical user-pays-merchant
flow may not be necessary in the merchant-pays-user flow (i.e., refund).

Add PrintableString utility

Strings defined by third parties may contain control characters. Provide
a wrapper such that these are replaced when displayed. Useful in node
aliases and offer fields.

Offer features for BOLT 12

The offer message in BOLT 12 contains a features TLV record. Add a
corresponding OfferFeatures type where the length is not included in the
serialization as it would be redundant with the record length.
Otherwise, define the features to be the same as InvoiceFeatures.

Make `process_pending_htlc_forwards` more readable

Refactor `process_pending_htlc_forwards` to ensure that both branches
that fails `pending_forwards` are placed next to eachother for improved
readability.

Consider `channel_id`s in `short_to_chan_info` as unguaranteed

As the `short_to_chan_info` map has been removed from the
`channel_state`, there is no longer any consistency guarantees between
the `by_id` and `short_to_chan_info` maps. This commit ensures that we
don't force unwrap channels where the channel_id has been queried from
the `short_to_chan_info` map.

Remove excess `channel_state` passing to macros

As the `short_to_chan_info` has been moved out of the `channel_state` to
a standalone lock, several macros no longer need the `channel_state`
passed into the macro.

Move `short_to_chan_info` into standalone lock

As the `channel_state` (`ChannelHolder`) struct will be removed, this
commit moves the `short_to_chan_info` map from that lock into a seperate
lock.

Remove empty match arm during prefix check

Merge pull request #1831 from benthecarman/hash-ConfirmationTarget

Implement Hash for ConfirmationTarget

Implement Hash for ConfirmationTarget

Merge pull request #1811 from valentinewallace/2022-10-chanman-router

Move `InflightHtlcs` and `Router` trait into `ChannelManager`

Merge pull request #1761 from TheBlueMatt/2022-10-user-idempotency-token

Provide `send_payment` idempotency guarantees