f - update OfferBuilder docs

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.

f - remove unneeded use of init_tlv_based_struct_field

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.

f - expand Offer docs

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

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.

Merge pull request #1725 from TheBlueMatt/2022-09-no-bench-lockorder

Stop building with lockorder debugging in benchmarks

Merge pull request #1694 from jurvis/jurvis/2022-08-move-scorer-from-router

Move `LockableScore` requirement away from `Router` trait

Move Scorer requirement away from Router trait

We do this to enable users to create routers that do not need a scorer.
This can be useful if they are running a node the delegates pathfinding.

* Move `Score` type parameterization from `InvoicePayer` and `Router` to
`DefaultRouter`
* Adds a new field, `scorer`, to `DefaultRouter`
* Move `AccountsForInFlightHtlcs` to `DefaultRouter`, which we
will use to wrap the new `scorer` field, so scoring only happens in
`DefaultRouter` explicitly.
* Add scoring related functions to `Router` trait that we used to call
directly from `InvoicePayer`.
* Instead of parameterizing `scorer` in `find_route`, we replace it with
inflight_map so `InvoicePayer` can pass on information about inflight
HTLCs to the router.
* Introduced a new tuple struct, InFlightHtlcs, that wraps functionality
for querying used liquidity.

Stop building with lockorder debugging in benchmarks

`cargo bench` sets `#[cfg(test)]` so our current checks for
enabling our lockorder debugging end up matching when we're trying
to build performance benchmarks.

This adds explicit checks to our debug_lockorder logic to filter
out `feature = "_bench_unstable"` builds.

Merge pull request #1708 from tnull/2022-09-rgs-unpub-modules

Improve RGS documentation

Add `no-std` support for RGS

Rework RGS crate-level docs

Merge pull request #1707 from TheBlueMatt/2022-09-no-global-features

Move supported-feature-set logic into the supporting modules

Assert that all defined features are in the known features set

Now that the features contexts track the full set of all known
features, rather than the set of supported features, all defined
features should be listed in the context definition macro.

This adds a compile-time assertion to check that all bits for known
features are set in the context known set.

Stop tracking feature bits as known or required in features.rs

Now that the `*Features::known` constructor has been removed, there
is no reason to define feature bits as either optional required in
`features.rs` - that logic now belongs in the modules that are
responsible for the given features.

Instead, we only list all features in each context.

Remove the `*Features::known` constructor

As we move towards specify supported/required feature bits in the
module(s) where they are supported, the global `known` feature set
constructors no longer make sense.

Here we (finally) remove the `known` constructor entirely,
modifying tests in the `features` module as required.

Remove all remaining references to `*Features::known`

As we move towards specify supported/required feature bits in the
module(s) where they are supported, the global `known` feature set
constructors no longer make sense.

In anticipation of removing the `known` constructor, this commit
removes all remaining references to it outside of features.rs.

Stop relying on `*Features::known` in fuzzing tests

As we move towards specify supported/required feature bits in the
module(s) where they are supported, the global `known` feature set
constructors no longer make sense.

Here we stop relying on the `known` method in our fuzz tests.

Stop relying on `*Features::known` in BP and persister tests

As we move towards specify supported/required feature bits in the
module(s) where they are supported, the global `known` feature set
constructors no longer make sense.

Here we stop relying on the `known` method in the
`lightning-background-processor` and `lightning-persister` crate
tests.

Stop relying on the `*Features::known` method in net-tokio

As we move towards specify supported/required feature bits in the
module(s) where they are supported, the global `known` feature set
constructors no longer make sense.

Here we stop relying on the `known` method in the
`lightning-net-tokio` crate.

Stop relying on the `*Features::known` method in lightning-invoice

As we move towards specify supported/required feature bits in the
module(s) where they are supported, the global `known` feature set
constructors no longer make sense.

Here we stop relying on the `known` method in the
`lightning-invoice` crate.

Stop relying on `*Features::known` in channel{,manager}.rs

As we move towards specify supported/required feature bits in the
module(s) where they are supported, the global `known` feature set
constructors no longer make sense.

Here we stop relying on the `known` method in the channel modules.

Stop relying on `*Features::known` in functional test utils

As we move towards specify supported/required feature bits in the
module(s) where they are supported, the global `known` feature set
constructors no longer make sense.

Here we stop relying on the `known` method in the
functional_test_utils module.

Stop relying on the `*Features::known` method in functional tests

This diff is commit, like the last, stops relying on the `known`
feature set constructor, doing so entirely with import changes and
sed rules.

Stop relying on the `*Features::known` method in `routing` tests

As we move towards specify supported/required feature bits in the
module(s) where they are supported, the global `known` feature set
constructors no longer make sense.

Here we stop relying on the `known` method in the `routing` module,
which was only used in tests.

List supported/required feature bits explicitly in ChannelManager

Historically, LDK has considered the "set of known/supported
feature bits" to be an LDK-level thing. Increasingly this doesn't
make sense - different message handlers may provide or require
different feature sets.

In a previous PR, we began the process of transitioning with
feature bits sent to peers being sourced from the attached message
handler.

This commit makes further progress by moving the concept of which
feature bits are supported by our ChannelManager into
channelmanager.rs itself, via the new `provided_*_features`
methods, rather than in features.rs via the `known_channel_features`
and `known` methods.

Merge pull request #1721 from acid-bit/fix_typo

Fix typo in comment in Cargo.toml

Merge pull request #1720 from TheBlueMatt/2022-09-fix-fuzz-warnings

Fix compile-time warnings in fuzzing

Fix typo in comment in Cargo.toml

Fix warnings in fuzz which should have been fixed in f725c5a90a11e6

Fix compile warning in fuzzing introduced in cd0d19c005ee4fa11de93a

Merge pull request #1685 from wpaulino/anchors-prep

Merge pull request #1717 from TheBlueMatt/2022-09-req-features-in-handlers

Move checking of specific require peer feature bits to handlers

Merge pull request #1706 from jkczyz/2022-09-filtered-blocks

Support filtered blocks in `lightning-block-sync`

Update anchors test vectors to zero HTLC transaction fee variant

Each test featuring HTLCs had a minimum and maximum feerate case. This
is no longer necessary for the zero HTLC transaction anchors variant as
the commitment feerate does not impact whether HTLCs can be trimmed or
not, only the dust limit does.

Account for zero fee HTLC transaction within dust limit calculation

With the zero fee HTLC transaction anchors variant, HTLCs can no longer
be trimmed due to their amount being too low to have a mempool valid
HTLC transaction. Now they can only be trimmed based on the dust limit
of each party within the channel.

Update HTLC script detection to check for anchor output variants

Use zero fee HTLC transactions for anchor channels

This is based on the assumption that we only support the zero HTLC
transaction fee variant of anchor channels.

Exclude HTLC transactions from broadcast on anchor channels

HTLC transactions from anchor channels are constrained by a CSV of 1
block, so broadcasting them along with the unconfirmed commitment
tranasction will result in them being immediately rejected as premature.

Avoid commitment broadcast upon detected funding spend

There's no need to broadcast our local commitment transaction if we've
already seen a confirmed one as it'll be immediately rejected as a
duplicate/conflict.

This will also help prevent dispatching spurious events for bumping
commitment and HTLC transactions through anchor outputs (once
implemented in future work) and the dispatch for said events follows the
same flow as our usual commitment broadcast.

Use proper sighash flag for remote HTLCs with anchor outputs

Support filtered blocks in lightning-block-sync

Expand the BlockSource trait to allow filtered blocks now that
chain::Listen supports them (d629a7edb7241eee7fde9f5ccdf1c481d2d6297b).
This makes it possible to use BIP 157/158 compact block filters with
lightning-block-sync.

Merge pull request #1703 from TheBlueMatt/2022-09-badonion-first-check

Correctly handle BADONION onion errors

Add now-missing `unwrap`s on test calls to `peer_connected`.

Move checking of specific require peer feature bits to handlers

As we remove the concept of a global "known/supported" feature set
in LDK, we should also remove the concept of a global "required"
feature set. This does so by moving the checks for specific
required features into handlers.

Specifically, it allows the handler `peer_connected` method to
return an `Err` if the peer should be disconnected. Only one such
required feature bit is currently set - `static_remote_key`, which
is required in `ChannelManager`.

Swap some `peer_connected` features to `known` from `empty` in test

In the next commit we'll enforce counterparty `InitFeatures`
matching our required set in `ChannelManager`, implying they must
be set for many tests where they previously did not need to be (as
they were enforced in `PeerManager`, which is not used in
functional tests).

Add a note that `peer_disconnected` impls must be idempotent

It appears our code is already correct here, but its also nice to
add a quick safety check in `channel.rs` which ensures we will
remain idempotent.

Add test for malformed update error with NODE bit set

Some tweaks by Matt Corallo <git@bluematt.me>

Correctly handle BADONION onion errors

Currently we entirely ignore the BADONION bit when deciding how to
handle HTLC failures. This opens us up to an attack where a
malicious node always fails HTLCs backwards via
`update_fail_malformed_htlc` with an error code of
`BADONION|NODE|PERM|X`. In this case, we may decide to interpret
this as a permanent node failure for the node encrypting the onion,
i.e. the counterparty of the node who sent the
`update_fail_malformed_htlc` message and ultimately failed the
HTLC.

Thus, any node we route through could cause us to fully remove its
counterparty from our network graph. Luckily we do not do any
persistent tracking of removed nodes, and thus will re-add the
removed node once it is re-announced or on restart, however we are
likely to add such persistent tracking (at least in-memory) in the
future.

Merge pull request #1712 from TheBlueMatt/2022-09-111

Cut 0.0.111

Bump versions to lightning* 0.0.111 and lightning-invoice 0.19

Update release notes for 0.0.111

Merge pull request #1714 from TheBlueMatt/2022-09-111-bindings-discovered-cleanups

Small Cleanups Discovered during Bindings for 0.0.111

Merge pull request #1715 from TheBlueMatt/2022-09-fix-msg-send

Fix encryption of broadcasted gossip messages

Update `Simple*PeerManager` type aliases to support Onion Messages

Note that `SimpleArcPeerHandler` is also updated to not wrap
`IgnoringMessageHandler` in an `Arc`, as `IgnoringMessageHandler`
is already zero-sized.

Export error type instead of entire modules

Previously the `error` and `processing` modules have been `pub`, leading
to them being included in the docs, altough (almost) empty.

Instead, we now `pub use` the `GraphSyncError` directly, cleaning up the
docs.

Merge pull request #1716 from TheBlueMatt/2022-09-log-unreadable-type

Include the message type when we send unreadable gossip msg errors

Encrypt+MAC most P2P messages in-place

For non-gossip-broadcast messages, our current flow is to first
serialize the message into a `Vec`, and then allocate a new `Vec`
into which we write the encrypted+MAC'd message and header.

This is somewhat wasteful, and its rather simple to instead
allocate only one buffer and encrypt the message in-place.

Fix encryption of broadcasted gossip messages

In 47e818f198abafba01b9ad278582886f9007dac2, forwarding broadcasted
gossip messages was split into a separate per-peer message buffer.
However, both it and the original regular-message queue are
encrypted immediately when the messages are enqueued. Because the
lightning P2P encryption algorithm is order-dependent, this causes
messages to fail their MAC checks as the messages from the two
queues may not be sent to peers in the order in which they were
encrypted.

The fix is to simply queue broadcast gossip messages unencrypted,
encrypting them when we add them to the regular outbound buffer.

Drop unused type parameter on `BlindedRoute::new`

I'm not sure why rustc didn't complain about the unused parameter
or why we're allowed to get away without explicitly bounding the
`Sign` in the `KeysInterface`, but the current code requires all
`BlindedPath` construction to explicitly turbofish an unused type.

Add relevant `(C-not exported)` tags on OnionMessenger aliases

The "helpful" type aliases don't make sense for C bindings as all
generics are concretized anyway.

Inline generic bounds rather than using the `where` clause

The bindings generator is pretty naive in its generic resolution
and doesn't like `where` clauses for bounds that are simple traits.
This should eventually change, but for now its simplest to just
inline the relevant generic bounds.

Do not use blanket impls when building for `c_bindings`

The C bindings generator isn't capable of figuring out if a blanket
impl applies in a given context, and instead opts to always write
out any relevant impl's for a trait. Thus, blanket impls should be
disabled when building with `#[cfg(c_bindings)]`.

Rename `{Signed,}RawInvoice::hash` to avoid naming collisions

Now that `{Signed,}RawInvoice` implement the std `Hash` trait,
having a method called `hash` is ambiguous.

Instead, we rename the `hash` methods `signed_hash` to make it
clear that the hash is the one used for the purpose of signing the
invoice.

Include the message type when we send unreadable gossip msg errors

Merge pull request #1710 from TheBlueMatt/2022-09-compile-warn

Fix several compile warnings added in some of my recent commits

Fix several compile warnings when testing in no-std mode

Fix (really dumb) warning rustc introduced in latest beta

Fix several compile warnings added in some of my recent commits

Merge pull request #1688 from valentinewallace/2022-08-flip-om-feature-bit

Onion messages: flip feature bit 🎉

Merge pull request #1713 from TheBlueMatt/2022-09-bad-doc-versions

Correct `get_claimable_balance` version info

Merge pull request #1711 from TheBlueMatt/2022-08-0conf-panic

Fix spurious panic on receipt of a block while awaiting funding

Update ChannelMessageHandler::provided_node_features docs

To be uniform with the other handler provided_node_features docs

Don't advertise onion messages in known channel features

OR InitFeatures and NodeFeatures from onion message handler

Similar to how we OR our InitFeaures and NodeFeatures across both our channel
and routing message handlers, we also want to OR the features of our onion
message handler.

Support forwarding onion messages in advertised features

In upcoming commit(s), onion message support will be advertised conditionally
based on the OnionMessageProvider provided to PeerManager.

Add missing wumbo feature bit docs

Add a new NodeFeatures constructor to capture the types of flags

When ChannelMessageHandler implementations wish to return a NodeFeatures which
contain all the known flags that are relevant to channel handling, but not
gossip  handling, they currently need to do so by manually constructing a
NodeFeatures with all known flags and then clearing the ones they don't want.

Instead of spreading this logic across the codebase, this consolidates such
construction into one place in features.rs.

OR NodeFeatures from both Channel and Routing message handlers

When we broadcast a node announcement, the features we support are really a
combination of all the various features our different handlers support. This
commit captures this concept by OR'ing our NodeFeatures across both our channel
and routing message handlers.

Correct `get_claimable_balance` version info

5a8ede09fb3c8bbcd8694d94c12dac9ea7485537 updated the documentation
on `get_claimable_balance` to note that if a channel went on-chain
with an LDK version older than 0.0.108 some
counterparty-revoked-output claimable balances my be missing.
However, this failed to account for the fact that we rely on the
entirely-new-in-0.0.111
`confirmed_commitment_tx_counterparty_output` field for some
balances as well.

Thus, the comment should have been in terms of 0.0.111, not
0.0.108.

Merge pull request #1709 from tnull/2022-09-make-access-error-debug

Derive `Debug` for `AccessError`

Fix spurious panic on receipt of a block while awaiting funding

When we receive a block we always test if we should send our
channel_ready via `check_get_channel_ready`. If the channel in
question requires confirmations, we quickly return if the funding
transaction has not yet confirmed (or even been defined), however
for 0conf channels the checks are necessarily more involved.

In any case, we wish to panic if the funding transaction has
confirmations prior to when it should have been broadcasted. This
is useful as it is easy for users to violate our broadcast-time
invariants without noticing and the panic gives us an opportunity
to catch it.

Sadly, in the case of 0conf channels, if we hadn't yet seen the
funding transaction at all but receive a block we would hit this
sanity check as we don't check whether there are actually funding
transaction confirmations prior to panicing.

Enable all feature sets to OR with another set of the same type

Merge pull request #1701 from TheBlueMatt/2022-09-feature-or

Fetch InitFeatures from both Channel and Routing Message Handlers

Make clear_initial_routing_sync more consistent with other APIs

Add a new InitFeatures constructor to capture the types of flags

When `ChannelMessageHandler` implementations wish to return an
`InitFeatures` which contain all the known flags that are relevant
to channel handling, but not gossip handling, they currently need
to do so by manually constructing an InitFeatures with all known
flags and then clearing the ones they dont want.

Instead of spreading this logic out across the codebase, this
consolidates such construction to one place in features.rs.

OR InitFeatures from both Channel and Routing message handlers

When we go to send an Init message to new peers, the features we
support are really a combination of all the various features our
different handlers support. This commit captures this concept by
OR'ing our InitFeatures across both our Channel and Routing
handlers.

Note that this also disables setting the `initial_routing_sync`
flag in init messages, as was intended in
e742894492c55802b241eebc585bbd28aa16481b, per the comment added on
`clear_initial_routing_sync`, though this should not be a behavior
change in practice as nodes which support gossip queries ignore the
initial routing sync flag.

Fetch our `InitFeatures` from `ChannelMessageHandler`

Like we now do for `NodeFeatures`, this converts to asking our
registered `ChannelMessageHandler` for our `InitFeatures` instead
of hard-coding them to the global LDK known set.

This allows handlers to set different feature bits based on what
our configuration actually supports rather than what LDK supports
in aggregate.

Derive `Debug` for `AccessError`

Merge pull request #1699 from TheBlueMatt/2022-08-announcement-rework

Merge pull request #1704 from TheBlueMatt/2022-09-always-probe-failed

Dont use PaymentPathFailed a probe fails without making it out

Add a folder to track CHANGELOG entries for the next release

Move `broadcast_node_announcement` to `PeerManager`

Some `NodeFeatures` will, in the future, represent features which
are not enabled by the `ChannelManager`, but by other message
handlers handlers. Thus, it doesn't make sense to determine the
node feature bits in the `ChannelManager`.

The simplest fix for this is to change to generating the
node_announcement in `PeerManager`, asking all the connected
handlers which feature bits they support and simply OR'ing them
together. While this may not be sufficient in the future as it
doesn't consider feature bit dependencies, support for those could
be handled at the feature level in the future.

This commit moves the `broadcast_node_announcement` function to
`PeerHandler` but does not yet implement feature OR'ing.

Send channel_{announcement,update} msgs on connection, not timer

When we connect to a new peer, immediately send them any
channel_announcement and channel_update messages for any public
channels we have with other peers. This allows us to stop sending
those messages on a timer when they have not changed and ensures
we are sending messages when we have peers connected, rather than
broadcasting at startup when we have no peers connected.

Improve debuggability when tests fail due to excess events

Dont use PaymentPathFailed a probe fails without making it out

When we fail to forward a probe HTLC at all and immediately fail it
(e.g. due to the first hop channel closing) we'd previously
spuriously generate only a `PaymentPathFailed` event. This violates
the expected API, as users expect a `ProbeFailed` event instead.

This fixes the oversight by ensuring we generate the correct event.

Thanks to @jkczyz for pointing out this issue.

Drop redundant code in `fail_holding_cell_htlcs`

`fail_holding_cell_htlcs` calls through to
`fail_htlc_backwards_internal` for HTLCs that need to be
failed-backwards but opts to generate its own payment failure
events for `HTLCSource:;OutboundRoute` HTLCs. There is no reason
for that as `fail_htlc_backwards_internal` will also happily
generate (now-)equivalent events for `HTLCSource::OutboundRoute`
HTLCs.

Thus, we can drop the redundant code and always call
`fail_htlc_backwards_internal` for each HTLC in
`fail_holding_cell_htlcs`.

Merge pull request #1702 from TheBlueMatt/2022-09-one-hop-retryable

Mark failed one-hop HTLCs as retrably