Disable LTO builds in tests (and bump deps to -O2)

For some reason rustc, at some point, decided that our optimization
of dependencies implies we want to also build with LTO. This causes
our test builds to take substantially longer to compile, even with
only a trivial change. By hard-disabling this (even keeping the
optimization of the test and in-tree libraries enabled) the time
required to build with only a trivial change to
`functional_tests.rs` goes from 0m25.635s wall clock/1m14.220s CPU
time to 0m17.841s wall clock/0m17.828s CPU time on my i7-13700K on
rustc 1.63.

The changes in test execution time appear to be within noise.

While we're at it, we also bump dependencies to build with -O2
because their build time is now substantially reduced cost.

Merge pull request #2050 from douglaz/import-lightning-io-futures

Only import lightning::io if futures are enabled

Only import lightning::io if futures are enabled

Merge pull request #2014 from valentinewallace/2023-02-rework-partial-pmt-fail

Rework auto-retry send errors

Clarify Retry::Timeout vs PaymentParams::expiry_time in docs

Fix outdated PendingOutboundPayment::Abandoned docs

On initial send retries, avoid previously failed scids

Previously, we could have tried the same failed channels over and over until
retries are exhausted.

In-line retry_with_route method

Since it's only used one place now

Rework auto retry send errors

Prior to this, we returned PaymentSendFailure from auto retry send payment
methods. This implied that we might return a PartialFailure from them, which
has never been the case. So it makes sense to rework the errors to be a better
fit for the methods.

We're taking error handling in a totally different direction now to make it
more asynchronous, see send_payment_internal for more information.

Fix InvalidRoute error to be ChannelUnavailable

InvalidRoute is reserved for malformed routes, not routes where a channel or
its peer is unavailable

Merge pull request #1897 from TheBlueMatt/2022-11-monitor-updates-always-async

Always process `ChannelMonitorUpdate`s asynchronously

Don't generate a `ChannelMonitorUpdate` for closed chans on shutdown

The `Channel::get_shutdown` docs are very clear - if the channel
jumps to `Shutdown` as a result of not being funded when we go to
initiate shutdown we should not generate a `ChannelMonitorUpdate`
as there's no need to bother with the shutdown script - we're
force-closing anyway.

However, this wasn't actually implemented, potentially causing a
spurious monitor update for no reason.

Use the new monitor persistence flow for `funding_created` handling

Building on the previous commits, this finishes our transition to
doing all message-sending in the monitor update completion
pipeline, unifying our immediate- and async- `ChannelMonitor`
update and persistence flows.

Use new monitor persistence flow in funding_signed handling

In the previous commit, we moved all our `ChannelMonitorUpdate`
pipelines to use a new async path via the
`handle_new_monitor_update` macro. This avoids having two message
sending pathways and simply sends messages in the "monitor update
completed" flow, which is shared between sync and async monitor
updates.

Here we reuse the new macro for handling `funding_signed` messages
when doing an initial `ChannelMonitor` persistence. This provides
a similar benefit, simplifying the code a trivial amount, but
importantly allows us to fully remove the original
`handle_monitor_update_res` macro.

Always process `ChannelMonitorUpdate`s asynchronously

We currently have two codepaths on most channel update functions -
most methods return a set of messages to send a peer iff the
`ChannelMonitorUpdate` succeeds, but if it does not we push the
messages back into the `Channel` and then pull them back out when
the `ChannelMonitorUpdate` completes and send them then. This adds
a substantial amount of complexity in very critical codepaths.

Instead, here we swap all our channel update codepaths to
immediately set the channel-update-required flag and only return a
`ChannelMonitorUpdate` to the `ChannelManager`. Internally in the
`Channel` we store a queue of `ChannelMonitorUpdate`s, which will
become critical in future work to surface pending
`ChannelMonitorUpdate`s to users at startup so they can complete.

This leaves some redundant work in `Channel` to be cleaned up
later. Specifically, we still generate the messages which we will
now ignore and regenerate later.

This commit updates the `ChannelMonitorUpdate` pipeline across all
the places we generate them.

Move TODO from `handle_monitor_update_res` into `Channel`

The TODO mentioned in `handle_monitor_update_res` about how we
might forget about HTLCs in case of permanent monitor update
failure still applies in spite of all our changes. If a channel is
drop'd in general, monitor-pending updates may be lost if the
monitor update failed to persist.

This was always the case, and is ultimately the general form of the
the specific TODO, so we simply leave comments there

Handle `MonitorUpdateCompletionAction`s after monitor update sync

In a previous PR, we added a `MonitorUpdateCompletionAction` enum
which described actions to take after a `ChannelMonitorUpdate`
persistence completes. At the time, it was only used to execute
actions in-line, however in the next commit we'll start (correctly)
leaving the existing actions until after monitor updates complete.

Merge pull request #1988 from TheBlueMatt/2023-01-limited-chans

Limit the number of pending un-funded inbound channel

Limit the number of pending un-funded inbound channel

Because we store some (not large, but not zero) state per-peer,
it's useful to limit the number of peers we have connected, at
least with some buffer.

Much more importantly, each channel has a relatively large cost,
especially around the `ChannelMonitor`s we have to build for each.

Thus, here, we limit the number of channels per-peer which aren't
(yet) on-chain, as well as limit the number of (inbound) peers
which don't have a (funded-on-chain) channel.

Fixes #1889

Add an `inbound` flag to the `peer_connected` message handlers

Its useful for the message handlers to know if a peer is inbound
for DoS decision-making reasons.

Merge pull request #2035 from TheBlueMatt/2023-02-fix-no-con-discon

Fix (and DRY) the conditionals before calling peer_disconnected

Merge pull request #2040 from alecchendev/2023-02-indexed-map-btreeset-to-vec

Replace `BTreeSet` in `IndexedMap` with sorted `Vec`

Remove the `peer_disconnected` `no_connection_possible` flag

Long ago, we used the `no_connection_possible` to signal that a
peer has some unknown feature set or some other condition prevents
us from ever connecting to the given peer. In that case we'd
automatically force-close all channels with the given peer. This
was somewhat surprising to users so we removed the automatic
force-close, leaving the flag serving no LDK-internal purpose.

Distilling the concept of "can we connect to this peer again in the
future" to a simple flag turns out to be ripe with edge cases, so
users actually using the flag to force-close channels would likely
cause surprising behavior.

Thus, there's really not a lot of reason to keep the flag,
especially given its untested and likely to be broken in subtle
ways anyway.

Add a further debug_assert that disconnecting peers are connected

Correct `funding_transaction_generated` err msg and fix fuzz check

This fixes new errors in `full_stack_target` pointed out by
Chaincode's generous fuzzing infrastructure. Specifically, there's
no reason to check the error message in the
`funding_transaction_generated` return value - it can only return
a failure if the channel has closed since the funding transaction
was generated (which is fine) or if the signer refuses to sign
(which can't happen in fuzzing).

Correct the "is peer live" checks in `PeerManager`

In general, we should be checking if a `Peer` has `their_features`
set as the "is this peer connected and have they finished the
handshake" flag as it indicates an `Init` message was received.

While none of these appear to be reachable bugs, there were a
number of places where we checked other flags for this purpose,
which may lead to sending messages before `Init` in the future.

Here we clean these cases up to always use the correct check (via
the new util method).

Add test of an initial message other than `Init`

This test fails without the previous commit.

Fix (and DRY) the conditionals before calling `peer_disconnected`

If we have a peer that sends a non-`Init` first message, we'll call
`peer_disconnected` without ever having called `peer_connected`
(which has to wait until we have an `Init` message). This is a
violation of our API guarantees, though should generally not be an
issue.

Because this bug was repeated in a few places, we also take this
opportunity to DRY up the logic which checks the peer state before
calling `peer_disconnected`.

Found by the new `ChannelManager` assertions and the
`full_stack_target` fuzzer.

Replace `BTreeSet` in `IndexedMap` with sorted `Vec`

The `Vec` is sorted not on `IndexedMap::insert`, but on
`IndexedMap::range` to avoid unnecessary work while reading a network
graph.

Pass pending_events into pay_internal

Useful for generating Payment(Path)Failed events in this method

Pass payment hash into pay_internal

Useful for generating Payment(Path)Failed events in this method

Merge pull request #2026 from valentinewallace/2023-02-dedup-pending-forwardable-evs

Deduplicate `PendingHTLCsForwardable` events on generation

Deduplicate PendingHTLCsForwardable events when queueing

On retryable update_fail, don't queue redundant PendingHTLCsForwardable

Check for abandon-able payments on startup

Add a new monitor update result handling macro

Over the next few commits, this macro will replace the
`handle_monitor_update_res` macro. It takes a different approach -
instead of receiving the message(s) that need to be re-sent after
the monitor update completes and pushing them back into the
channel, we'll not get the messages from the channel at all until
we're ready for them.

This will unify our message sending into only actually fetching +
sending messages in the common monitor-update-completed code,
rather than both there *and* in the functions that call `Channel`
when new messages are originated.

Add storage for `ChannelMonitorUpdate`s in `Channel`s

In order to support fully async `ChannelMonitor` updating, we need
to ensure that we can replay `ChannelMonitorUpdate`s if we shut
down after persisting a `ChannelManager` but without completing a
`ChannelMonitorUpdate` persistence. In order to support that we
(obviously) have to store the `ChannelMonitorUpdate`s in the
`ChannelManager`, which we do here inside the `Channel`.

We do so now because in the coming commits we will start using the
async persistence flow for all updates, and while we won't yet
support fully async monitor updating it's nice to get some of the
foundational structures in place now.

Track actions to execute after a `ChannelMonitor` is updated

When a `ChannelMonitor` update completes, we may need to take some
further action, such as exposing an `Event` to the user initiating
another `ChannelMonitor` update, etc. This commit adds the basic
structure to track such actions and serialize them as required.

Note that while this does introduce a new map which is written as
an even value which users cannot opt out of, the map is only filled
in when users use the asynchronous `ChannelMonitor` updates. As
these are still considered beta, breaking downgrades for such users
is considered acceptable here.

Add an infallible no-sign version of send_commitment_no_status_check

In the coming commits we'll move to async `ChannelMonitorUpdate`
application, which means we'll want to generate a
`ChannelMonitorUpdate` (including a new counterparty commitment
transaction) before we actually send it to our counterparty. To do
that today we'd have to actually sign the commitment transaction
by calling the signer, then drop it, apply the
`ChannelMonitorUpdate`, then re-sign the commitment transaction to
send it to our peer.

In this commit we instead split `send_commitment_no_status_check`
and `send_commitment_no_state_update` into `build_` and `send_`
variants, allowing us to generate new counterparty commitment
transactions without actually signing, then build them for sending,
with signatures, later.

Fix the err msg provided when a send fails due to peer disconnected

We haven't had a `MonitorUpdateInProgress` check in
`Channel::is_live` for some time.

Merge pull request #2009 from TheBlueMatt/2023-02-no-racey-retries

Fix (and test) threaded payment retries

Fix (and test) threaded payment retries

The new in-`ChannelManager` retries logic does retries as two
separate steps, under two separate locks - first it calculates
the amount that needs to be retried, then it actually sends it.
Because the first step doesn't udpate the amount, a second thread
may come along and calculate the same amount and end up retrying
duplicatively.

Because we generally shouldn't ever be processing retries at the
same time, the fix is trivial - simply take a lock at the top of
the retry loop and hold it until we're done.

Always check `next_route` in `TestRouter` is fully consumed

...rather than only in std.

Test if a given mutex is locked by the current thread in tests

In anticipation of the next commit(s) adding threaded tests, we
need to ensure our lockorder checks work fine with multiple
threads. Sadly, currently we have tests in the form
`assert!(mutex.try_lock().is_ok())` to assert that a given mutex is
not locked by the caller to a function.

The fix is rather simple given we already track mutexes locked by a
thread in our `debug_sync` logic - simply replace the check with a
new extension trait which (for test builds) checks the locked state
by only looking at what was locked by the current thread.

Merge pull request #2037 from valentinewallace/2023-02-fix-probe-leak

Fix outbound payments probe leak

Merge pull request #1921 from arik-so/2022-12-prohibit-old-rgs-updates

Throw error for RGS data that's more than two weeks old

Throw error for RGS data that's more than two weeks old, fixing #1785

Remove pending probes on update_fail

Previously we had a memory leak where probes would not be removed from
outbound_payments on htlc fail

Merge pull request #2008 from valentinewallace/2023-02-remove-manual-retries

Abandon payments on behalf of the user and remove manual retries

Reword and fix grammar in PartialFailure docs

Remove retry_payments method

We're no longer supporting manual retries since
ChannelManager::send_payment_with_retry can be parameterized by a retry
strategy

This commit also updates all docs related to retry_payment and abandon_payment.
Since these docs frequently overlap with changes in preceding commits where we
start abandoning payments on behalf of the user, all the docs are updated in
one go.

When processing pending htlcs, abandon outbounds that are not retryable

Abandon payment on behalf of the user on payment path failure

Removed retry_single_path_payment, it's replaced by automatic_retries with
AutoRetry::Success

Abandon payment if retry fails in process_pending_htlcs

Merge pull request #1832 from jkczyz/2022-11-composite-handler

Macro for composing custom message handlers

Pass pending events to outbound_payments::abandon_payment

This makes it uniform with the outbound payment methods that generate events
and set us up for abandoning payments on behalf of the user.

Fix indentation in outbound payment mark_abandoned

Merge pull request #2020 from valentinewallace/2023-02-test-inflight-scoring

Fix and test in-flight HTLC scoring in between retries

Add CI testing for lightning-custom-message crate

Re-write CustomMessageHandler documentation

Documentation for CustomMessageHandler wasn't clear how it is related to
PeerManager and contained some grammatical and factual errors. Re-write
the docs and link to the lightning_custom_message crate.

Fix compilation errors in some doc tests

These are seen in newer versions of rustc.

Macro for composing custom message handlers

BOLT 1 specifies a custom message type range for use with experimental
or application-specific messages. While a `CustomMessageHandler` can be
defined to support more than one message type, defining such a handler
requires a significant amount of boilerplate and can be error prone.

Add a crate exporting a `composite_custom_message_handler` macro for
easily composing pre-defined custom message handlers. The resulting
handler can be further composed with other custom message handlers using
the same macro.

This requires a separate crate since the macro needs to support "or"
patterns in macro_rules, which is only available in edition 2021.

https://doc.rust-lang.org/edition-guide/rust-2021/or-patterns-macro-rules.html

Otherwise, a crate defining a handler for a set of custom messages could
not easily be reused with another custom message handler. Doing so would
require explicitly duplicating the reused handlers type ids, but those
may change when the crate is updated.

Move `fairrwlock` to the `sync` module

Merge pull request #2029 from wpaulino/update-pgp-key

Update Wilmer Paulino's PGP key

Remove unnecessary scoring methods from Router trait

Fix computing in-flight HTLCs in between retries + test

test_utils: parameterize TestRouter by TestScorer

This allows us set scoring expectations and ensure in-flight htlcs are factored
into scoring

Merge pull request #1966 from ViktorTigerstrom/2023-01-store-channels-per-peer-followups

1507 followups

Don't serialize nodes which we have no channels to

Initialize `list_channels_with_filter` result vec with capacity

Update unknown peer passed to msg and api functions handling

Always remove disconnected peers with no channels

When a peer disconnects but still has channels, the peer's `peer_state`
entry in the `per_peer_state` is not removed by the `peer_disconnected`
function. If the channels with that peer is later closed while still
being disconnected (i.e. force closed), we therefore need to remove the
peer from `peer_state` separately.

To remove the peers separately, we push such peers to a separate HashSet
that holds peers awaiting removal, and remove the peers on a timer to
limit the negative effects on parallelism as much as possible.

Update `ChannelManager` docs

Updates multiple instances of the `ChannelManager` docs related to the
previous change that moved the storage of the channels to the
`per_peer_state`. This docs update corrects some grammar errors and
incorrect information, as well as clarifies documentation that was
confusing.

Check `peer_state` existence more idiomatically

Remove redundant Vec in `get_and_clear_pending_msg_events`

Don't clone the Vec in `remove_first_msg_event_to_node`

Remove redundant hashmap lookups

Avoid doing the same hashmap lookups twice in a row, when it's not
needed. Refactor `claim_funds_from_hop` in order to enable this change.

Update Wilmer Paulino's PGP key

The old key (729E9D9D92C75A5FBFEEE057B5DD717BEF7CA5B1) has been revoked
as of 2023-02-11.

All commits going forward will be signed with the new key.

Merge pull request #1980 from TheBlueMatt/2023-01-async-utxo-lookups

Merge pull request #2019 from tnull/2023-02-expose-peer-addrs

Expose peer addresses in `PeerManager`

Merge pull request #2027 from danielgranhao/fix-create-inbound-payment-docs

Fix out-of-date `create_inbound_payment()` docs

Test `get_peer_nodeids` returns peer addresses

Expose peer addresses via `get_peer_node_ids`

Fix out-of-date `create_inbound_payment()` docs

Merge pull request #1870 from tnull/2022-11-add-transaction-sync-crate

Add transaction sync crate

Build and test transaction sync crate in CI

Test syncing against Esplora backend

Add transaction sync crate

This crate provides utilities for syncing LDK via the transaction-based
`Confirm` interface. The initial implementation facilitates
synchronization with an Esplora backend server.

Move the channel_announcement process log into `NetworkGraph`

This ensures its always written after we update the graph, no
matter how we updated the graph.

Add tests for the new async gossip checking internal APIs

Support async results in `TestChainSource`, count `get_utxo` calls

Suggest a socket read buffer of 4KiB to limit message count

...and switch the same in `lightning-net-tokio`

Don't apply gossip backpressure to non-channel-announcing peers

When we apply the new gossip-async-check backpressure on peer
connections, if a peer has never sent us a `channel_announcement`
at all, we really shouldn't delay reading their messages.

This does so by tracking, on a per-peer basis, whether they've sent
us a channel_announcement, and resetting that state whenever we're
not backlogged.

Apply backpressure when we have too many gossip checks in-flight

Now that the `RoutingMessageHandler` can signal that it needs to
apply message backpressure, we implement it here in the
`PeerManager`. There's not much complicated here, aside from noting
that we need to add the ability to call `send_data` with no data
to indicate that reading should resume (and track when we may need
to make such calls when updating the routing-backpressure state).

Allow `RoutingMessageHandler` to signal backpressure

Now that we allow `handle_channel_announcement` to (indirectly)
spawn async tasks which will complete later, we have to ensure it
can apply backpressure all the way up to the TCP socket to ensure
we don't end up with too many buffers allocated for UTXO
validation.

We do this by adding a new method to `RoutingMessageHandler` which
allows it to signal if there are "many" checks pending and
`channel_announcement` messages should be delayed. The actual
`PeerManager` implementation thereof is done in the next commit.

Forward gossip messages which were verified asynchronously

Gossip messages which were verified against the chain
asynchronously should still be forwarded to peers, but must now go
out via a new `P2PGossipSync` parameter in the
`AccessResolver::resolve` method, allowing us to wire them up to
the `P2PGossipSync`'s `MessageSendEventsProvider` implementation.

Add the ability to broadcast gossip msgs via the event pipeline

When we process gossip messages asynchronously we may find that we
want to forward a gossip message to a peer after we've returned
from the existing `handle_*` method. In order to do so, we need to
be able to send arbitrary loose gossip messages back to the
`PeerManager` via `MessageSendEvent`.

This commit modifies `MessageSendEvent` in order to support this.

Process `channel_update`/`node_announcement` async if needed

If we have a `channel_announcement` which is waiting on a UTXO
lookup before we can process it, and we receive a `channel_update`
or `node_announcement` for the same channel or a node which is a
part of the channel, we have to wait until the lookup completes
until we can decide if we want to accept the new message.

Here, we store the new message in the pending lookup state and
process it asynchronously like the original `channel_announcement`.

Track in-flight `channel_announcement` lookups and avoid duplicates

If we receive two `channel_announcement`s for the same channel at
the same time, we shouldn't spawn a second UTXO lookup for an
identical message. This likely isn't too rare - if we start syncing
the graph from two peers at the same time, it isn't unlikely that
we'll end up with the same messages around the same time.

In order to avoid this we keep a hash map of all the pending
`channel_announcement` messages by SCID and simply ignore duplicate
message lookups.

Add an async resolution option to `ChainAccess::get_utxo`

For those operating in an async environment, requiring
`ChainAccess::get_utxo` return information about the requested UTXO
synchronously is incredibly painful. Requesting information about a
random UTXO is likely to go over the network, and likely to be a
rather slow request.

Thus, here, we change the return type of `get_utxo` to have both a
synchronous and asynchronous form. The asynchronous form requires
the user construct a `AccessFuture` which they `clone` and pass
back to us. Internally, an `AccessFuture` has an `Arc` to the
`channel_announcement` message which we need to process. When the
user completes their lookup, they call `resolve` on their
`AccessFuture` which we pull the `channel_announcement` from and
then apply to the network graph.