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

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

Provide `send_payment` idempotency guarantees

Merge pull request #1817 from TheBlueMatt/2022-10-removed-no-score-after

Merge pull request #1743 from tnull/2022-09-channel-events

Add `ChannelReady` event

Fix warnings for ununsed anchor imports

Previously introduced during release commit.

Rename chan state `ChannelFunded` to `ChannelReady`

We rename `ChannelState::ChannelFunded` to `ChannelState::ChannelReady`
as we'll be in this state when both sides sent the `ChannelReady`
messages, which may also be before funding in the 0conf case.

Add `ChannelReady` event

This adds a `ChannelReady` event that is emitted as soon as a new
channel becomes usable, i.e., after both sides have sent
`channel_ready`.

Add missing break when scoring a path with a missing channel

If we send payments over a path where a channel ended up being
closed, we'll remove it before we call
`ProbabilisticPaymentScorer::payment_path_failed`. This should be
fine, except that `payment_path_failed` does not break out of its
scoring loop if a channel is missing, causing it to assign a
minimum available-liquidity of the payment amount even to channels
which our attempt never arrived at.

The fix is simple - add the missing check and break.

Merge pull request #1735 from naumenkogs/2022-09-prune-channels-if-either-not-upd

Prune channels if either not updated + track pruning time

Merge pull request #1753 from wpaulino/avoid-redundant-claims-after-initial-conf

Avoid generating redundant claims after initial confirmation

Avoid generating redundant claims after initial confirmation

These claims will never be valid as a previous claim has already
confirmed. If a previous claim is reorged out of the chain, a new claim
will be generated bypassing the new behavior.

While this doesn't change much for our existing transaction-based
claims, as broadcasting an already confirmed transaction acts as a NOP,
it prevents us from yielding redundant event-based claims, which will be
introduced as part of the anchors patchset.

Track the time a stale channel was pruned

Add a pending changelog entry for the past few commits

Allow users to specify the `PaymentId` used in `InvoicePayer`

In order to allow users to pass a custom idempotency key to the
`send*` methods in `InvoicePayer`, we have to pipe the `PaymentId`
through to the `Payer` methods, which we do here.

By default, existing `InvoicePayer` methods use the `PaymentHash`
as the `PaymentId`, however we also add duplicate `send*_with_id`
methods which allow users to pass a custom `PaymentId`.

Finally, appropriate documentation updates are made to clarify
idempotency guarantees.

Test that PaymentIds are idempotency keys until `abandon_payment`

Stop timing out payments automatically, requiring abandon_payment

When the `abandon_payment` flow was added there was some concern
that upgrading users may not migrate to the new flow, causing
memory leaks in the pending-payment tracking.

While this is true, now that we're relying on the
pending_outbound_payments map for `send_payment` idempotency, the
risk of removing a payment prematurely goes up from "spurious
retry failure" to "sending a duplicative payment", which is much
worse.

Thus, we simply remove the automated payment timeout here,
explicitly requiring that users call `abandon_payment` when they
give up retrying a payment.

Delay removal of fulfilled outbound payments for a few timer ticks

Previously, once a fulfilled outbound payment completed and all
associated HTLCs were resolved, we'd immediately remove the payment
entry from the `pending_outbound_payments` map.

Now that we're using the `pending_outbound_payments` map for send
idempotency, this presents a race condition - if the user makes a
redundant `send_payment` call at the same time that the original
payment's last HTLC is resolved, the user would reasonably expect
the `send_payment` call to fail due to our idempotency guarantees.

However, because the `pending_outbound_payments` entry is being
removed, if it completes first the `send_payment` call will
succeed even though the user has not had a chance to see the
corresponding `Event::PaymentSent`.

Instead, here, we delay removal of `Fulfilled`
`pending_outbound_payments` entries until several timer ticks have
passed without any corresponding event or HTLC pending.

Allow users to specify the `PaymentId` for new outbound payments

In c986e52ce83e9aeaa9447abebc5f6600470337cf, an `MppId` was added
to `HTLCSource` objects as a way of correlating HTLCs which belong
to the same payment when the `ChannelManager` sees an HTLC
succeed/fail. This allows it to have awareness of the state of all
HTLCs in a payment when it generates the ultimate user-facing
payment success/failure events. This was used in the same PR to
avoid generating duplicative success/failure events for a single
payment.

Because the field was only used as an internal token to correlate
HTLCs, and retries were not supported, it was generated randomly by
calling the `KeysInterface`'s 32-byte random-fetching function.
This also provided a backwards-compatibility story as the existing
HTLC randomization key was re-used for older clients.

In 28eea12bbe0d78d256f79ec725cf02366dce4e36 `MppId` was renamed to
the current `PaymentId` which was then used expose the
`retry_payment` interface, allowing users to send new HTLCs which
are considered a part of an existing payment.

At no point has the payment-sending API seriously considered
idempotency, a major drawback which leaves the API unsafe in most
deployments. Luckily, there is a simple solution - because the
`PaymentId` must be unique, and because payment information for a
given payment is held for several blocks after a payment
completes/fails, it represents an obvious idempotency token.

Here we simply require the user provide the `PaymentId` directly in
`send_payment`, allowing them to use whatever token they may
already have for a payment's idempotency token.

Merge pull request #1791 from valentinewallace/2022-10-we-are-intro-node

Onion messages: fix edge case where we are the intro node

Prune channels if *either* not updated

Non-mandatory "fix" enabling future tests

Merge pull request #1815 from TheBlueMatt/2022-10-dead-gossip-code

Require directional updates for a DirectionalChannelInfo

Merge pull request #1818 from TheBlueMatt/2022-10-stable-bench

Use rustc stable for benchmark CI run to fix current breakage

Use rustc stable for benchmark CI run to fix current breakage

OMs: fix panic sending to a two-hop blinded route where we are the intro node

Onion messages: fix edge case where we are the introduction node

If we're sending straight to a blinded route with no unblinded intermediate
hops, and we are the introduction node, we need to advance the blinded route by
one hop so that the second hop is the new introduction node.

Make `htlc_maximum_msat` in `EffectiveCapacity` non-`Option`al

Because we now never generate an `EffectiveCapacity` with an
`htlc_maximum_msat` set to `None`, making it non-`Option`al
effectively removes dead code, which we do here.

Require directional updates for a `DirectionalChannelInfo`

We currently construct `DirectedChannelInfo`s for routing before
checking if the given direction has its directional info filled in.
We then always check for directional info before actually deciding
to route over a channel, as otherwise we assume the channel is not
online.

This makes for somewhat redundant checks, and `DirectedCHannelInfo`
isn't, by itself, a very useful API. Because fetching the HTLC-max
or effective channel capacity gives spurious data if no directional
info is available, there's little reason to have that data
available, and so we here check for directional info first. This
effectively merges `DirectionalChannelInfo` and
`DirectionalChannelInfoWithUpdate`.

Merge pull request #1809 from valentinewallace/2022-10-custom-om-self

Give us a self when reading a custom onion message

Give us a self when reading a custom onion message

+ remove MaybeReadableArgs trait as it is now unused
+ remove onion_utils::DecodeInput as it would've now needed to be parameterized
by the CustomOnionMessageHandler trait, and we'd like to avoid either
implementing DecodeInput in messenger or having onion_utils depend on
onion_message::*

Co-authored-by: Matt Corallo <git@bluematt.me>
Co-authored-by: Valentine Wallace <vwallace@protonmail.com>

Merge pull request #1805 from TheBlueMatt/2022-10-remote-useless-mut

Drop useless `mut` in `KeysInterface::sign_holder_anchor_input`

Merge pull request #1807 from TheBlueMatt/2022-10-errorkind-bindings

Export io::ErrorKind in bindings

Export io::ErrorKind in bindings

The bindings have exported `io::Error` as, basically,
`io::ErrorKind`, for quite some time, so there's little reason to
not just export `io::ErrorKind` as well.

Drop useless `mut` in `KeysInterface::sign_holder_anchor_input`

The `Transaction` is not modified so there's no reason to make the
reference `mut`

Merge pull request #1797 from arik-so/2022-10-channel-manager-deparameterization

Deparametrize `ChannelManager` to infer `Signer` from its `KeysInterface`.

Merge pull request #1802 from TheBlueMatt/2022-10-112

Add release date and release name to CHANGELOG for 0.0.112

Refer to `lnd` as `LND` in CHANGELOG

for consistency since its an abbreviation for "lightning network
daemon".

Add release date and release name to CHANGELOG for 0.0.112

Merge pull request #1798 from TheBlueMatt/2022-10-112

Cut 0.0.112

Deparametrize `ChannelManager` to infer `Signer` from its `KeysInterface`.

Add release notes for 0.0.112

Remove outdated allow(unused)

Bump crate versions to 0.0.112/invoice 0.20

Do not export new anchors structs in `events.rs` without anchors

This avoids adding unused, effectively-dummy public structs in
`events.rs`.

Merge pull request #1779 from valentinewallace/2022-10-node-pk-keysinterface

Add `KeysInterface::get_node_id` method

KeysInterface docs: note that Recipient type must be supported by impl

Merge pull request #1780 from wpaulino/rust-edition-2018

Bump workspace to rust edition 2018

Mostly motivated by the need of async/await.

Add KeysInterface::get_node_id method

Useful since we're working on getting rid of KeysInterface::get_node_secret to
complete support for remote signing.

Will be used in upcoming work to check whether an outbound onion message
blinded path has our node id as the introduction node id

Merge pull request #1770 from jkczyz/2022-10-debug-route-hints

Add logging in route hint filtering

Merge pull request #1788 from TheBlueMatt/2022-10-mtlc-writer

Add `WriteableScore` bindings impl for `MultiThreadedLockableScore`

Add `WriteableScore` bindings impl for `MultiThreadedLockableScore`

In 56b07e52aabdaca521987e765f1fa864966a5d49 we made
`MultiThreadedLockableScore` fully bindings-compatible. However, it
did not add a `WriteableScore` implementation for it. This was an
oversight as it is a `WriteableScore` in Rust and needs to be for
use in other parts of the API.

Here we add the required impl in a way that the bindings generator
is able to handle it and add conversion utilities.

Add logging in route hint filtering

Knowing why a channel was not included as an invoice route hint can be
valuable. Add logging on the decisions made when filtering channels.

Merge pull request #1748 from valentinewallace/2022-10-custom-oms

Support custom onion messages

Disallow sending invalid custom OM TLVs

Onion message data TLV types must be >= 64, enforce this on send

Implement sending and receiving custom onion messages

This uses the work done in the preceding commits to implement encoding a user's
custom TLV in outbound onion messages, and decoding custom TLVs in inbound
onion messages, to be provided to the new CustomOnionMessageHandler.

Merge pull request #1678 from TheBlueMatt/2022-08-funding-locked-mon-persist-fail

Handle async initial ChannelMonitor persistence failing on restart

Rename `ChannelState::MonitorUpdateFailed` `MonitorUpdateInProgress`

As we're moving towards monitor update async being a supported
use-case, we shouldn't call an async monitor update "failed", but
rather "in progress". This simply updates the internal channel.rs
enum name to reflect the new thinking.

Handle async initial ChannelMonitor persistence failing on restart

If the initial ChannelMonitor persistence is done asynchronously
but does not complete before the node restarts (with a
ChannelManager persistence), we'll start back up with a channel
present but no corresponding ChannelMonitor.

Because the Channel is pending-monitor-update and has not yet
broadcasted its initial funding transaction or sent channel_ready,
this is not a violation of our API contract nor a safety violation.
However, the previous code would refuse to deserialize the
ChannelManager treating it as an API contract violation.

The solution is to test for this case explicitly and drop the
channel entirely as if the peer disconnected before we received
the funding_signed for outbound channels or before sending the
channel_ready for inbound channels.

Merge pull request #1769 from TheBlueMatt/2022-10-disconnected-hints

Include all channel route hints if no connected channels exist

Merge pull request #1764 from G8XSU/rgs-ignore-error

Ignore Duplicate Gossip Error while updating networkGraph from RGS

Merge pull request #1777 from lexe-tech/max/best-block-header-best-block

Add `.to_best_block()` method to `ValidatedBlockHeader`

Merge pull request #1689 from wpaulino/anchors-bump-channel-close-event

Clean up private channel route hint filtering

Add `ValidatedBlockHeader::to_best_block`

Include all channel route hints if no connected channels exist

Mobile clients often take a second or two before they reconnect to
their peers as its not always clear immediately that connections
have been killed (especially on iOS). This can cause us to
spuriously fail to include route hints in our invoices if we're on
mobile.

The fix is simple, if we're selecting channels to include in route
hints and we're not not connected to the peer for any of our
channels, we should simply include the hints for all channels, even
though we're disconencted.

Fixes #1768.

Add public helper to build anchor input witnesses

Add holder anchor signing support to BaseSign

Document expected call frequency of ChainMonitor::process_pending_events

Yield channel close bump events

Generate ClaimEvent for HolderFundingOutput inputs from anchor channels

Refactor generate_claim_tx to return OnchainClaim enum

Split finalize_package into separate methods per malleability

Track funding amount in HolderFundingOutput

This will be useful later on when determining the appropriate fee rate
to use on the anchor transaction to bump its commitment transaction.

Track whether HolderFundingOutput originated from an anchor channel

Store anchors option for supported output types

As we integrate the support of anchor outputs, we'll want to know if
each input we're working with came from an anchor outputs channel.
Instead of threading through a `opt_anchors` boolean across several
methods on `PackageSolvingData` and `PackageTemplate`, we decide to
store a reference in each `PackageSolvingData` variant instead that
features a change in behavior between channels with and without anchor
outputs.

Dedupe gossip msgs while updating networkGraph from RGS

While applying gossip info from RGS-server, number of harmless
errors might arise which should be ignored. E.g. client should not
fail if there is a duplicate gossip for same channel or duplicate
update.

Update send_onion_message API to take new OnionMessageContents enum

OnionMessageContents specifies the data TLV that the sender wants in the onion
message. This enum only has one variant for now, Custom. When offers are added,
additional variants for invoice, invoice_request, and invoice_error will be
added.

This commit does not actually implement sending the custom OM contents, just
the API change.

Fix accidental newline in OnionMessenger docs

Tweak OnionMessenger log on inbound onion message receipt

Parameterize OnionMessenger by new CustomOnionMessageHandler trait

OnionMessenger::new will now take a custom onion message handler trait
implementation. This handler will be used in upcoming commit(s) to handle
inbound custom onion messages.

The new trait also specifies what custom messages are supported via its
associated type, CustomMessage. This associated type must implement a new
CustomOnionMessagesContents trait, which requires custom messages to support
being written, being read, and supplying their TLV type.

Optionally parameterize decode_tlv_stream with custom decode closure

Useful for decoding custom or user-provided TLVs. See macro docs for more info.

Used in upcoming commit(s) to support custom onion message TLVs

ser: Add MaybeReadableArgs trait

Useful in decoding a custom message, so (a) the message type can be provided to
the handler and (b) None can be returned if the message type is unknown.

Used in upcoming commit(s) to support custom onion messages.

Merge pull request #1763 from gcomte/feature/derive-eq

Derive Eq for all structs that derive PartialEq

Merge pull request #1774 from futurepaul/disable-rustfmt

disable automatic formatting

disable all formatting

Derive Eq for all structs that derive PartialEq

Merge pull request #1765 from gcomte/refactor/remove-redundant-field-names

Remove redundant field names

Remove redundant field names

Merge pull request #1754 from TheBlueMatt/2022-10-better-liq-halflife-docs

Rewrite some documentation on `ProbabilisticScorer` and increase half-life to 6 hours.

Increase the default `liquidity_offset_half_life` to six hours

Even at relatively high payment volumes, decaying knowledge of each
individual channel every hour causes aggressive retrying of
channels as we quickly forget the state of a channel. Even with the
historical tracker, this isn't fully remedied, as we'll track the
history bounds with the decayed value.

Instead, we decay every six hours here, reducing how often we'll
retry a channel due to decay.

In addition to this, the decay likely needs to be substantially
more linear, as tracked in #1752.

Rewrite documentation some on `ProbabilisticScorer`

We had some user confusion on how the probabilistic scorer works,
especially in reference to the half-life parameter. This attempts
to clarify how the bounds work, and how they are decayed.

Merge pull request #1744 from tnull/2022-09-fix-bp-futures-doc

Fix `background-processor` doc build for `futures`

Add `futures` CI check

This adds testing of the `futures` feature to CI. In order to avoid
introducing a dependency on `std`, we switch to using the `futures-util`
crate directly enabling only a subset of features. To this end, we also
switch to using the `select_biased!` macro, which is equivalent to
`select!` except that it doesn't choose ready futures pseudo-randomly
at runtime.

Fix `background-processor` doc build for `futures`

Merge pull request #1756 from TheBlueMatt/2022-10-rgs-no-std

Fix `rapid-gossip-sync` `no-std` and properly test no-std in CI

Specify full import path in decode_tlv macro

Prevents unresolved import error

Merge pull request #1649 from dunxen/2022-08-implementnodefailure

Implement permanent node failure handling

Merge pull request #1693 from valentinewallace/2022-09-readme-updates

Fix outdated README sections