Correct payment resolution after on chain failure of dust HTLCs

Previously, we wouldn't mark a dust HTLC as permanently resolved if
the commitment transaction went on chain. This resulted in us
always considering the HTLC as pending on restart, when we load the
pending payments set from the monitors.

Fixes #1653.

Move open_zero_conf_channel utility to common test utils

Merge pull request #1643 from jurvis/jurvis/2022-07-inflights-htlcs-across-payments

Track in-flight HTLCs across payments when routing

Make payment tests more realistic

Made sure that every hop has a unique receipient. When we simulate
calling `channel_penalty_msat` in `TestRouter`’s find route, use
actual previous node ids instead of just using the payer’s.

Keep track of inflight HTLCs across payments

Added two methods, `process_path_inflight_htlcs` and
`remove_path_inflight_htlcs`, that updates that `payment_cache` map with
path information that may have failed, succeeded, or have been given up
on.

Introduced `AccountForInflightHtlcs`, which will wrap our user-provided
scorer. We move the `S:Score` type parameterization from the `Router` to
`find_route`, so we can use our newly introduced
`AccountForInflightHtlcs`.

`AccountForInflightHtlcs` keeps track of a map of inflight HTLCs by
their short channel id, direction, and give us the value that is being
used up.

This map will in turn be populated prior to calling `find_route`, where
we’ll use `create_inflight_map`, to generate a current map of all
inflight HTLCs based on what was stored in `payment_cache`.

Merge pull request #1687 from TheBlueMatt/2022-08-fuzz-msrv

Drop honggfuzz `arbitrary` dependency to meet MSRV

Drop honggfuzz `arbitrary` dependency to meet MSRV

Change `payment_cache` to accept `PaymentInfo`

Introduces a new `PaymentInfo` struct that contains both the previous
`attempts` count that was tracked as well as the paths that are also
currently inflight.

Merge pull request #1604 from valentinewallace/2022-07-OMs-followup

Onion messages: add some initial rate limiting

Implement buffering onion messages for peers.

In this commit, we check if a peer's outbound buffer has room for onion
messages, and if so pulls them from an implementer of a new trait,
OnionMessageProvider.

Makes sure channel messages are prioritized over OMs, and OMs are prioritized
over gossip.

The onion_message module remains private until further rate limiting is added.

Implement OnionMessageProvider for OnionMessenger

PeerManager: bump the read pause limit

...to make sure we can still get channel messages out after enqueuing some big gossip messages.

Add boilerplate for sending and receiving onion messages in PeerManager

Adds the boilerplate needed for PeerManager and OnionMessenger to work
together, with some corresponding docs and misc updates mostly due to the
PeerManager public API changing.

Merge pull request #1683 from valentinewallace/2022-08-multiqueue-peerman

Merge pull request #1673 from TheBlueMatt/2022-08-may-learn-preimage-balance

Expose a `Balance` for inbound HTLCs even without a preimage

Separate gossip broadcasts into their own queue in PeerManager

This allows us to better prioritize channel messages over gossip broadcasts and
lays groundwork for rate limiting onion messages more simply, since they won't
be competing with gossip broadcasts for space in the main message queue.

PeerMan: rename drop_gossip util to be more accurate

It's more accurate to name it as dropping gossip broadcasts, as it won't drop
all gossip.

PeerMan: fix bug in drop_gossip util

Fixes a flipped bool that was introduced in
4a1ee5f9a984c9b0c0892025d624ade734337b1a

Rename MaybeClaimableHTLCAwaitingTimeout for consistency

As we now have a MaybePreimageClaimableHTLC, its more consistent
to rename `MaybeClaimableHTLCAwaitingTimeout` to
`MaybeTimeoutClaimableHTLC`.

Expose a `Balance` for inbound HTLCs even without a preimage

If we don't currently have the preimage for an inbound HTLC, that
does not guarantee we can never claim it, but instead only that we
cannot claim it unless we receive the preimage from the channel we
forwarded the channel out on.

Thus, we cannot consider a channel to have no claimable balances if
the only remaining output on the commitment ransaction is an
inbound HTLC for which we do not have the preimage, as we may be
able to claim it in the future.

This commit addresses this issue by adding a new `Balance` variant
- `MaybePreimageClaimableHTLCAwaitingTimeout`, which is generated
until the HTLC output is spent.

Fixes #1620

Merge pull request #1682 from tnull/2022-08-export-all-log-levels

Merge pull request #1652 from valentinewallace/2022-08-reply-paths

Onion messages: support reply paths

Export and document all `log` macros.

Previously, only `log_error` and `log_trace` macros have been exported.
This change exports the macros of all log levels, which enables them to
be used downstream.

Support sending and receiving reply paths

Fix bug in onion message payload decode

Previously, we were decoding payload lengths as a VarInt. Per the spec, this is
wrong -- it should be decoded as a BigSize.  This bug also exists in our
payment payload decoding, to be fixed separately.

Upcoming reply path tests caught this bug because we hadn't encoded a payload
greater than 253 before, so we hadn't hit the problem that VarInts are encoded
as little-endian whereas BigSizes are encoded as big-endian.

OM functional tests: update util to take nodes by reference

And fix one test to be uniform with the others

Merge pull request #1679 from TheBlueMatt/2022-08-no-double-access

Avoid querying the chain for outputs for channels we already have

Avoid querying the chain for outputs for channels we already have

If we receive a ChannelAnnouncement message but we already have the
channel, there's no reason to do a chain lookup. Instead of
immediately calling the user-provided `chain::Access` when handling
a ChannelAnnouncement, we first check if we have the corresponding
channel in the graph.

Note that if we do have the corresponding channel but it was not
previously checked against the blockchain, we should still check
with the `chain::Access` and update if necessary.

Merge pull request #1681 from dunxen/2022-08-githubactionsfix

Workaround GH Actions issue for 1.45

Workaround GH Actions issue for 1.45

Merge pull request #1677 from ok300/ok300-patch-1

Bump bitcoin_hashes to v0.11

Merge pull request #1676 from arik-so/2022-08-gossip-error-message-fix

Fix script order in gossip key mismatch error.

Merge pull request #1575 from NicolaLS/hash-invoice

Fix script order in gossip key mismatch error.

derive Hash for Invoice

Bump bitcoin_hashes to v0.11

Merge pull request #1670 from TheBlueMatt/2022-08-mon-size-guidelines

Provide guidance on ChannelMonitorUpdate serialized size

Merge pull request #1495 from TheBlueMatt/2022-04-all-claimables

Expose counterparty-revoked-outputs in `get_claimable_balance`

Provide guidance on ChannelMonitorUpdate serialized size

Users need to make decisions about storage sizing and we need to
have advice on the maximum size of various things users need to
store. ChannelMonitorUpdates are likely the worst case of this,
they're usually at max a few KB, but can get up to a few hundred
KB for commitment transactions that have 400+ HTLCs pending.

We had one user report an update (likely) going over 400 KiB, which
isn't immediately obvious to me is practical, but its within a few
multiples of trivially-reachable sizes, so its likely that did
occur. To be on the safe side, we simply recommend users ensure
they can support "upwards of 1 MiB" here.

Merge pull request #1648 from valentinewallace/2022-08-fuzz-onion-msgs

Onion messages: add fuzz testing

Merge pull request #1666 from TheBlueMatt/2022-08-fix-script-check

Correct the on-chain script checked in gossip verification

Correct the on-chain script checked in gossip verification

The `bitcoin_key_1` and `bitcoin_key_2` fields in
`channel_announcement` messages are sorted according to node_ids
rather than the keys themselves, however the on-chain funding
script is sorted according to the bitcoin keys themselves. Thus,
with some probability, we end up checking that the on-chain script
matches the wrong script and rejecting the channel announcement.

The correct solution is to use our existing channel funding script
generation function which ensure we always match what we generate.

This was found in testing the Java bindings, where a test checks
that retunring the generated funding script in `chain::Access`
results in the constructed channel ending up in our network graph.

Fuzz test onion messages

Also update the fuzz ChaCha20Poly1305 to not mark as finished after a single
encrypt_in_place.  This is because more bytes may still need to be encrypted,
causing us to panic at the assertion that finished == false when we go to
encrypt more.

Also fix unused_mut warning in messenger + add log on OM forward for testing

Merge pull request #1660 from TheBlueMatt/2022-08-cleanup-ratelimits

Backfill gossip without buffering directly in LDK

Move per-HTLC logic out of get_claimable_balances into a helper

Val suggested this as an obvious cleanup to separate per_HTLC logic
from the total commitment transaction logic, separating the large
function into two.

Expose counterparty-revoked-outputs in `get_claimable_balance`

This uses the various new tracking added in the prior commits to
expose a new `Balance` type - `CounterpartyRevokedOutputClaimable`.

Some nontrivial work is required, however, as we now have to track
HTLC outputs as spendable in a transaction that comes *after* an
HTLC-Success/HTLC-Timeout transaction, which we previously didn't
need to do. Thus, we have to check if an
`onchain_events_awaiting_threshold_conf` event spends a commitment
transaction's HTLC output while walking events. Further, because
we now need to track HTLC outputs after the
HTLC-Success/HTLC-Timeout confirms, and because we have to track
the counterparty's `to_self` output as a contentious output which
could be claimed by either party, we have to examine the
`OnchainTxHandler`'s set of outputs to spend when determining if
certain outputs are still spendable.

Two new tests are added which test various different transaction
formats, and hopefully provide good test coverage of the various
revoked output paths.

Drop uneccessary `if {...; bool}` pattern in PeerManager

Replace manual iteration with for loops in outbound gossip sync

Simplify claimable balance trivially with consistent accessors

Scan `onchain_events_awaiting_threshold_conf` once in balance calc

Instead of a series of different
`onchain_events_awaiting_threshold_conf.iter()...` calls to scan
for HTLC status in balance calculation, pull them all out into one
`for ... { match ... }` to do it once and simplify the code
somewhat.

Track the txid that resolves HTLCs even after resolution completes

We need this information when we look up if we still need to spend
a revoked output from an HTLC-Success/HTLC-Timeout transaction for
balance calculation.

Track HTLC-Success/HTLC-Timeout claims of revoked outputs

When a counterparty broadcasts a revoked commitment transaction,
followed immediately by HTLC-Success/-Timeout spends thereof, we'd
like to have an `onchain_events_awaiting_threshold_conf` entry
for them.

This does so using the `HTLCSpendConfirmation` entry, giving it
(slightly) new meaning. Because all existing uses of
`HTLCSpendConfirmation` already check if the relevant commitment
transaction is revoked first, this should be trivially backwards
compatible.

We will ultimately figure out if something is being spent via the
`OnchainTxHandler`, but to do so we need to look up the output via
the HTLC transaction txid, which this allows us to do.

Fix off-by-one in test_onchain_htlc_claim_reorg_remote_commitment

The test intended to disconnect a transaction previously connected
but didn't disconnect enough blocks to do so, leading to it
confirming two conflicting transactions.

In the next few commits this will become an assertion failure.

Clean up nesting in `get_counterparty_output_claim_info`

Track counterparty payout info in counterparty commitment txn

When handling a revoked counterparty commitment transaction which
was broadcast on-chain, we occasionally need to look up which
output (and its value) was to the counterparty (the `to_self`
output). This will allow us to generate `Balance`s for the user for
the revoked output.

Store the full event transaction in `OnchainEvent` structs

When we see a transaction which generates some `OnchainEvent`, its
useful to have the full transaction around for later analysis.
Specifically, it lets us check the list of outputs which were spent
in the transaction, allowing us to look up, e.g. which HTLC
outpoint was spent in a transaction.

This will be used in a few commits to do exactly that - figure out
which HTLC a given `OnchainEvent` corresponds with.

Merge pull request #1663 from tnull/2022-08-drop-register-output-return

Drop return value from `Filter::register_output`

Backfill gossip without buffering directly in LDK

Instead of backfilling gossip by buffering (up to) ten messages at
a time, only buffer one message at a time, as the peers' outbound
socket buffer drains. This moves the outbound backfill messages out
of `PeerHandler` and into the operating system buffer, where it
arguably belongs.

Not buffering causes us to walk the gossip B-Trees somewhat more
often, but avoids allocating vecs for the responses. While its
probably (without having benchmarked it) a net performance loss, it
simplifies buffer tracking and leaves us with more room to play
with the buffer sizing constants as we add onion message forwarding
which is an important win.

Note that because we change how often we check if we're out of
messages to send before pinging, we slightly change how many
messages are exchanged at once, impacting the
`test_do_attempt_write_data` constants.

Clarify 'should' vs 'will' in `get_relevant_txids`

Drop return value from `Filter::register_output`

This commit removes the return value from `Filter::register_output` as
creating a suitable value almost always entails blocking operations
(e.g., lookups via network request), which however conflicts with the
requirement that user calls should avoid blocking calls at all cost.

Removing the return value also rendered quite a bit of test code for
dependent transaction handling superfluous, which is therefore also
removed with this commit.

Merge pull request #1659 from valentinewallace/2022-08-fix-payload-decode

Fix payment onion payload decode

Fix fuzzer-found underflow

Rename HighZeroBytesDroppedVarInt to HighZeroBytesDroppedBigSize

As observed by @wpaulino, this struct encodes its bytes as big-endian,
therefore it's a BigSize, not a VarInt.

Fix bug in onion payment payload decode

Prior to this change, we could have failed to decode a valid payload of size
>253. This is because we were decoding the length (a BigSize, big-endian) as a
VarInt (little-endian).

Found in #1652.

Merge pull request #1658 from lightning-signer/2022-08-bitcoin-0-29

Update bitcoin crate to 0.29.0

Modify ecdh to take Scalar

Update bitcoin crate to 0.29.0

Clarify comment on BUFFER_DRAIN_MSGS_PER_TICK.

Use util methods in `Peer` to decide when to forward

This consolidates our various checks on peer buffer space into the
`Peer` impl itself, making the thresholds at which we stop taking
various actions on a peer more readable as a whole.

This commit was primarily authored by `Valentine Wallace
<vwallace@protonmail.com>` with some amendments by `Matt Corallo
<git@bluematt.me>`.

Merge pull request #1655 from valentinewallace/2022-08-fix-ci-doc-links-check

Fix CI to error on doc links to private items

Merge pull request #1651 from TheBlueMatt/2022-08-export-chan-list

[C Bindings] Expose channel and nodes list in `ReadOnlyNetworkGraph`

Merge pull request #1654 from TheBlueMatt/2022-08-update-libfuzzer

Update libfuzzer-sys to new upstream inclusion method

Update libfuzzer-sys to new upstream inclusion method

Dunno why they changed it, but the old "depend directly on git"
thing that cargo-fuzz used forever is now deprecated that that
repo is archived, they've now moved to another repo and publish
properly on crates.io.

Fix CI to error on doc links to private items

Somehow we weren't doing this.

Minor msgs::OnionHopData cleanups

[C Bindings] Expose channel and nodes list in `ReadOnlyNetworkGraph`

Merge pull request #1638 from ViktorTigerstrom/2022-07-update-decode-update-add-htlc-onion-return-parameters

Don't return `channel_state` from `decode_update_add_htlc_onion`

Merge pull request #1619 from G8XSU/main

Add config support for 'their_channel_reserve_proportional_millionths' [#1498]

Merge pull request #1503 from valentinewallace/2022-05-onion-msgs

Onion messages v1

Fix possible incomplete read bug on onion packet decode

Pre-existing to this PR, we were reading next packet bytes with io::Read::read,
which is not guaranteed to read all the bytes we need, only guaranteed to read
*some* bytes.

We fix this to be read_exact, which is guaranteed to read all the next hop
packet bytes.

Error when attempting to send an OM to a blinded route with 0 hops

Add SendError enum for onion messages and error on too-big packets

Add test utilities and integration tests for onion messages

Significantly expand onion message documentation

Implement receiving and forwarding onion messages

This required adapting `onion_utils::decode_next_hop` to work for both payments
and onion messages.

Currently we just print out the path_id of any onion messages we receive. In
the future, these received onion messages will be redirected to their
respective handlers: i.e. an invoice_request will go to an InvoiceHandler,
custom onion messages will go to a custom handler, etc.

Support sending onion messages

This adds several utilities in service of then adding
OnionMessenger::send_onion_message, which can send to either an unblinded
pubkey or a blinded route. Sending custom TLVs and sending an onion message
containing a reply path are not yet supported.

We also need to split the construct_keys_callback macro into two macros to
avoid an unused assignment warning.

Add baseline OnionMessenger and msgs::OnionMessage and its serialization

OnionMessenger will be hooked up to the PeerManager to send and receive OMs in
a follow-up PR.

KeysInterface: add new ecdh method

This method will help us avoid retrieving our node secret, something we want to
get rid of entirely.  It will be used in upcoming commits when decoding the
onion message packet, and in future PRs to help us get rid of
KeysInterface::get_node_secret usages across the codebase

Add onion_message::Packet and adapt construct_onion_packet_with_init_noise for it

We need to add a new Packet struct because onion message packet hop_data fields
can be of variable length, whereas regular payment packets are always 1366
bytes.

Co-authored-by: Valentine Wallace <vwallace@protonmail.com>
Co-authored-by: Jeffrey Czyz <jkczyz@gmail.com>

Add config support for 'their_channel_reserve_proportional_millionths' [#1498]

It is proportion of the channel value to configure as the
`their_channel_reserve_satoshis` for both outbound and inbound channels.
It decides the minimum balance that the other node has to maintain on their
side, at all times.

Don't return `channel_state` from `decode_update_add_htlc_onion`

Currently `decode_update_add_htlc_onion` returns the `channel_state`
lock to ensure that `internal_update_add_htlc` holds a single
`channel_state` lock in when the entire function execution. This is
unnecessary, and since we are moving the channel storage to the
`per_peer_state`, this no longer achieves the goal it was intended for.

We therefore avoid returning the `channel_state` from
`decode_update_add_htlc_onion`, and just retake the lock in
`internal_update_add_htlc` instead.

Merge pull request #1637 from tnull/2022-07-contrib-remove-slack

Remove Slack and update `CONTRIBUTING`

Remove Slack and update `CONTRIBUTING`

Add onion messages module + enable the construction of blinded routes

Blinded routes can be provided as destinations for onion messages, when the
recipient prefers to remain anonymous.

We also add supporting utilities for constructing blinded path keys, and
control TLVs structs representing blinded payloads prior to being
encoded/encrypted. These utilities and struct will be re-used in upcoming
commits for sending and receiving/forwarding onion messages.

Finally, add utilities for reading the padding from an onion message's
encrypted TLVs without an intermediate Vec.

Merge pull request #1628 from tnull/2022-07-readme-remove-slack

Remove Slack link and other updates to `README`

Merge pull request #1635 from TheBlueMatt/2022-07-accessor-pub

Expose `ChannelMonitor::get_counterparty_node_id`

Merge pull request #1633 from TheBlueMatt/2022-07-110

Set release date on 0.0.110 release

Merge pull request #1632 from TheBlueMatt/2022-07-warnings

Fix compilation warnings

Remove 'slack' (and other things)

Expose `ChannelMonitor::get_counterparty_node_id`

This fixes an oversight in ac842ed9dd7a36a4a26eb6b856d80ab04eecf750
namely that it left users unable to implement their own
`ChainMonitor` from outside of the `rust-lightning` crate.