Fix `lightning-block-sync` builds below rustc 1.56 due to serde_json

Merge pull request #2400 from TheBlueMatt/2023-07-kill-vec_type

Fix backwards compat for blocked_monitor_updates and finally kill `vec_type`

Document some TLV write/read formats

While we don't want to publicly document these and support them for
downstream crates, documenting them internally is useful.

Drop `vec_type` TLV handling entirely

Historically, we used `vec_type` for all TLV Vec reads/writes, but
it is asymmetric and thus somewhat confusing - on the write side it
always writes a TLV entry, even if there are zero elements. On the
read side, it happily accepts a missing TLV, providing a
zero-length vector.

In 85b573ddad70f3c5ee36e0992d587842af507a8d a new `optional_vec`
TLV format was added which was symmetric, but only supports
optional vecs.

Now that we've migrated entirely to the new `required_vec` TLV
type, we can entirely remove the awkward `vec_type`.

Convert `channelmonitor` `vec_type` TLV writes to required/optional

 * `HolderSignedTx::htlc_outputs` has always been written since it
   was converted to TLVs in 86641ea68062388a01c99c6ed131f56477c8e4.
 * `ChanelMonitorUpdateStep::*::htlc_outputs` have been written
   since the enum was converted to TLVs in 86641ea68062388a01c99c6.

Merge pull request #2395 from wpaulino/phantom-deduped-forward-event

Force enqueue second forward event for phantom receives

Merge pull request #2369 from TheBlueMatt/2023-06-mon-event-less-race

Don't drop ChannelMonitor Events until they're processed

Don't drop `ChannelMonitor` `Event`s until they're processed

We currently assume the owner of `ChannelMonitor`s won't persist
the `ChannelMonitor` while `Event`s are being processed. This is
fine, except (a) its generally hard to do so and (b) the
`ChainMonitor` doesn't even do this.

Thus, in rare cases, a user could begin processing events which
are, generated by connecting a transaction or a new best-block,
take some time to do so, and while doing so process a further chain
event, causing persistece. This could lose the event being
processed alltogether, which could lose the user funds.

This should be very rare, but may have been made slightly more
reachable with (a) the async event processing making it more
common to do networking in event handling, (b) the new future
generation in the `ChainMonitor`, which now wakes the
`background-processor` directly when chain actions happen on the
`ChainMonitor`.

Handle new event processing logic when enqueuing forward event

This was a regression resulting from f2453b7 since we now process events
in a loop until there aren't any left. Processing events is done in
batches and they are not removed until we're done processing each batch.
Since handling a `PendingHTLCsForwardable` event will call back into the
`ChannelManager`, we'll still see the original forwarding event not
removed. Phantom payments will need an additional forwarding event
before being claimed to make them look real by taking more time.

Merge pull request #2364 from TheBlueMatt/2023-06-htlc-preimage-replay

Re-claim forwarded HTLCs on startup

Merge pull request #2307 from benthecarman/verify-funcs

Add helper functions to verify node and channel annoucements

Merge pull request #2042 from ffaex/add_fn

added fn_add_htlc

Merge pull request #2396 from tnull/2023-07-fix-github-actions

Update CI to remove deprecated actions

Add helper functions to verify node and channel annoucements

Right now the only real way to verify the node and channel
announcements is to call `update_node_from_announcement`/
`update_channel_from_announcement`. If you want to do some
processing before you add to your network graph then you need to
manually verify the signature. This adds some nice helper functions
to make it easier.

I tried to do the same for channel update but it did not seem as
easy so figured that is fine to punt on since I don't see many
people doing manual things with channel updates.

Rename `ClosingMonitorUpdateRegeneratedOnStartup` to `Closed...`

Now that we also use the "Closing" `BackgroundEvent` for
already-closed channels we need to rename it and tweak the docs.

Re-claim forwarded HTLCs on startup

Because `ChannelMonitorUpdate`s can complete asynchronously and
out-of-order now, a `commitment_signed` `ChannelMonitorUpdate` from
a downstream channel could complete prior to the preimage
`ChannelMonitorUpdate` on the upstream channel. In that case, we may
not get a `update_fulfill_htlc` replay on startup. Thus, we have to
ensure any payment preimages contained in that downstream update are
re-claimed on startup.

Here we do this during the existing walk of the `ChannelMonitor`
preimages for closed channels.

Merge pull request #2354 from alecchendev/2023-06-bump-default-dust-exp

Bump dust exposure threshold

Merge pull request #2347 from henghonglee/issue-2304

Expose whether a channel is closing in ChannelDetails

Replace `vec_type` TLVs in channel/manager with required/optional

* `PhantomRouteHints::channels` has been written since the struct
  was added in 410eb053656b1a4d3a6c506f1902e456a69324ac.
* `HTLCSource::path_hops` has been written since the struct was
  converted to TLVs in 66784e32fe454e9a5b2080b85fc4d8816ac5e436.

Convert routing `vec_type `TLV writes to other TLV types

 * `BlindedTail::hops` has always been written since it was
   introduced in 64c26c8a793f35c55076a2188912e92106900bab.
 * `PaymentParameters::clear_hints` has always been written since
   it was introduced as `Payee::route_hitns` in 46b68c517dba57bde5.

Migrate `chan_utils` `vec_type` TLVs to required/optional

* `CommitmentTransaction::htlcs` has always been written since the
  struct was converted to TLVs in 66784e32fe454e9a5b2080b85fc4d881.
* `HolderCommitmentTransaction::counterparty_htlc_sigs` have always
  been written since the struct was converted to TLVs in
  c8bc1b6d3de45aeddc755d0875b3dce8d86f79c1.

Convert `Event` vec storage away from `vec_type`

 * `PaymentPathFailed::path` was added without an optional compat
   wrapper in e5310dd5f0347fcaaf21b2742a1084f97fc84bd8.
 * `PaymentPathSuccessful::path` has always been written since the
   event was added in 2c4f16d5e39e6d4e90d1b9836cceaad11810fbaa.
 * `Probe{Failed,Successful}::path` have always been written since
   the events were added in eb8bce0d161d5d6c135be5fd8c7ebe2699857a.

Convert some `vec_type` TLVs to `required_vec`

This converts some required TLVs to `required_vec` which are, in
fact, required (and have been written forever).

* `HTLCFailReason` hasn't changed since many structs were converted
  to TLVs in 66784e32fe454e9a5b2080b85fc4d8816ac5e436.
* `NodeInfo::channels` has been written since `NetworkGraph`
  structs were converted to TLVs in 321b19c4d96a49b39b5583d0f12fea.
* Several test-only TLV writes were converted.

Add a `required_vec` TLV deserialization type

Historically, we used `vec_type` for all TLV Vec reads/writes, but
it is asymmetric and thus somewhat confusing - on the write side it
always writes a TLV entry, even if there are zero elements. On the
read side, it happily accepts a missing TLV, providing a
zero-length vector.

In 85b573ddad70f3c5ee36e0992d587842af507a8d a new `optional_vec`
TLV format was added which was symmetric, but only supports
optional vecs. This adds the corresponding required form, always
writing a TLV and ensuring it is present.

Use multiplier in dust exposure threshold calculation

This commit makes use of the added enum to calculate the dust
exposure threshold based on the current fee rate. This also updates
tests to ensure it works as intended.

Send fee estimator through to `get_max_htlc_dust_exposure_threshold`

Add max dust exposure multiplier config knob

With fee rates rising dramatically in mid-April 2023, thresholds for
what is considered dust have risen, often exceeding our previous dust
exposure threshold of 5k sats. This causes all payments and HTLC
forwards between 5k sats and new dust thresholds to fail.

This commit changes our max dust exposure config knob from a fixed
upper limit to a `MaxDustHTLCExposure` enum with an additional variant
to allow setting our max dust exposure to a multiplier on the current
high priority feerate.

To remain backwards compatible we'll always write the fixed limit if
it's set, or its default value in its currently reserved TLV.

We also now write an odd TLV for the new enum, so that previous
versions can safely ignore it upon downgrading, while allowing us to
make use of the new type when it's written.

Fix backwards compat for `blocked_monitor_updates`

In 1ce2beb77455a674888f3e3589723195eaa7b13c,
`Channel::blocked_monitor_updates` was moved to an even TLV to
ensure downgrades with vec entries are forbidden. However, the
serialized type remained `vec_type`, which is always written.

Instead, `optional_vec` must be used.

Merge pull request #2392 from TheBlueMatt/2023-07-async-mon-even-tlv

Move Channel's blocked monitor updates vec to an even TLV

Merge pull request #2399 from tnull/2023-07-expose-default-message-router

Expose `DefaultMessageRouter`

Expose `DefaultMessageRouter`

Merge pull request #2383 from henghonglee/fix-dyn

Fix DefaultRouter type restrained to only MutexGuard

Update Github Actions to remove deprecated actions

Add ChannelShutdownState to ChannelDetails

This commit adds the state of channel shutdown to channeldetails

Move Channel's blocked monitor updates vec to an even TLV

In 9dfe42cf8681afc9c3f84e0c85a4e2a30c1156a8,
`ChannelMonitorUpdate`s were stored in `Channel` while they were
being processed. Because it was possible (though highly unlikely,
due to various locking likely blocking persistence) an update was
in-flight (even synchronously) when a `ChannelManager` was
persisted, the new updates were persisted via an odd TLV.

However, in 4041f0899f86eaf6a0a4576a91918fa54026ac46 these pending
monitor updates were moved to `ChannelManager`, with appropriate
handling there. Now the only `ChannelMonitorUpdate`s which are
stored in `Channel` are those which are explicitly blocked, which
requires the async pipeline.

Because we don't support async monitor update users downgrading to
0.0.115 or lower, we move to persisting them via an even TLV. As
the odd TLV storage has not yet been released, we can do so
trivially.

Fixes #2317.

Fix DefaultRouter type restrained to only MutexGuard

Type of DerefMut for DefaultRouter was specialized to only MutexGuard.
It should be generic around RefMut and MutexGuard. This commit fixes that

Merge pull request #2384 from jkczyz/2023-06-message-router

Define a default `MessageRouter` implementation

Merge pull request #2375 from TonyGiorgio/remove-doc-future-anchor-support

Remove doc specifying future anchor support

Define a default MessageRouter implementation

Otherwise, users need to define one when using "Simple" type aliases.

Merge pull request #2386 from TheBlueMatt/2023-06-macos-msrv

Fix 1.54- builds with the `backtrace` feature due to MSRV breakage

Fix 1.54- builds with the `backtrace` feature due to MSRV breakage

The test-only `backtrace` feature broke on rustc prior to 1.55.

Clarify event doc specifying anchor support

Merge pull request #2322 from andrei-21/fix/instant-overflow

Merge pull request #2372 from wpaulino/channelmanager-new-highest-seen-timestamp

Require best block timestamp within ChannelManager::new

Use `MonotonicTime` as `Instant` shifted by 10 years forward

Such implementation allows `MonotonicTime` to go backward up to 10
years on all platforms. On some platforms (e.g. iOS) `Instant` is
represented as `u64` of nanoseconds since the boot of the system.
Obviously such implementation does not allow to go backward before the
time of the boot.

Co-authored-by: Andrei <andrei.i@posteo.de>
Co-authored-by: Jeffrey Czyz <jkczyz@gmail.com>

Require best block timestamp within ChannelManager::new

This ensures freshly initialized nodes can proceed to create unexpired
invoices without a call to `best_block_updated`, since an invoice's
expiration delta is applied to `highest_seen_timestamp`.

Some minor comment/doc tweaks in new monitor update blocking code

A few nits that came up in review to make the docs clearer, but not
anything super critical.

Merge pull request #2374 from arik-so/2023-06-build-warning-fixes

Fix build warnings

Fix clone warning on nightly.

Remove redundant `mut`s in router.rs.

Fix warning about deserialization marker.

Specifically, the legacy deserialization
prevention marker variable was not being
read.

Fix build warning about HTLCSource::dummy().

Fix build warning about public_from_secret_hex.

Merge pull request #2368 from wpaulino/inbound-anchors-manual-acceptance

Require inbound channels with anchor outputs to be accepted manually

Merge pull request #2367 from wpaulino/remove-anchors-flag

Remove anchors config flag

Require inbound channels with anchor outputs to be accepted manually

Since the use of channels with anchor outputs requires a reserve of
onchain funds to handle channel force closures, it would be
irresponsible to allow a node to accept inbound channel without first
consulting such reserves. To allow users to do so, we require such
channels be manually accepted.

Merge pull request #2373 from TheBlueMatt/2023-06-116-alpha

Support manual inbound acceptance in channel creation test utils

Merge pull request #2362 from TheBlueMatt/2023-06-unblocked-mons-in-manager

Move in-flight ChannelMonitorUpdates to ChannelManager

Remove anchors config flag

Now that all of the core functionality for anchor outputs has landed,
we're ready to remove the config flag that was temporarily hiding it
from our API.

Bump versions to LDK 116-alpha1 and invoice 24.0-alpha1

Rename `Channel::pending_monitor_updates` to `blocked`

To differentiate between in-flight pending completion and blocked
updates.

Rename Channel's latest-monitor-update fetch method for clarity

`Channel::get_latest_complete_monitor_update_id` no longer refers
to complete updates, but rather ones which were passed to the
`ChannelManager` and which the `CHannel` no longer knows about.
Thus, we rename it `get_latest_unblocked_monitor_update_id`.

Remove the `blocked` param on `ChannelMonitorUpdates` in `Channel`

Now that all `ChannelMonitorUpdate`s stored in `Channel` are
blocked we don't need a bool to track it.

Drop the now-unused update_id param to monitor update macros

Move in-flight `ChannelMonitorUpdate`s to `ChannelManager`

Because `ChannelMonitorUpdate`s can be generated for a
channel which is already closed, and must still be tracked
through their completion, storing them in a `Channel`
doesn't make sense - we'd have to have a redundant place to
put them post-closure and handle both storage locations
equivalently.

Instead, here, we move to storing in-flight
`ChannelMonitorUpdate`s to the `ChannelManager`, leaving
blocked `ChannelMonitorUpdate`s in the `Channel` as they
were.

Merge pull request #2361 from arik-so/2023-06-anchor-channel-type-features

Replace `opt_anchors` with `ChannelTypeFeatures`

Sync `ChannelTransactionParameters` features to `ChannelContext`.

Verify channel type features for decoding.

Replace `opt_anchors` with `ChannelTypeFeatures`

This change modifies six structs that were keeping
track of anchors features with an `opt_anchors` field,
as well as another field keeping track of nonzero-fee-
anchor-support.

Merge pull request #2365 from TheBlueMatt/2023-06-fix-fuzz-dep

Ensure we build if a downstream crate sets `--cfg=fuzzing`

Method for `ChannelTypeFeatures` serialization compatibility.

Define `ChannelTypeFeatures` methods for anchors logic.

Specifically, introduce a new constructor for an anchors-
supporting feature set, as well as methods that will
maintain forwards-compatible deserialization in older
versions.

Reference-rhs bitwise operations for features.

Document nonzero anchors in features module.

Introduce nonzero fee anchors feature.

Simplify cases in `handle_new_monitor_update` macro

By giving up on a tiny bit of parallelism and tweaking the return
types, we can make the `handle_new_monitor_update` macro a bit
clearer - now the only cases where its called after a monitor was
updated was when the monitor was initially committed.

Drop the now-unused `push_blockable_mon_update`

Move most `handle_new_monitor_update` calls to pass the update

Most of the calls to the `handle_new_monitor_update` macro had the
exact same pattern - calling `update_monitor` followed by the
macro. Given that common pattern will grow to first pushing the
new monitor onto an in-flight set and then calling `update_monitor`
unifying the pattern into a single macro now avoids more code churn
in the coming commits.

Return owned `ChannelMonitorUpdate`s from `Channel`

In the coming commits we'll move to storing in-flight
`ChannelMonitorUpdate`s in the `ChannelManager` rather in the
`Channel` (which will then only retain `ChannelMonitorUpdate`s
which have not yet been released/are blocked.

This will simplify handling of pending `ChannelMonitorUpdate` after
a channel has closed by not having to move them into the
`ChannelManager`.

Merge pull request #2319 from valentinewallace/2023-05-forward-less-than-onion

Allow forwarding less than the amount in the onion

Ensure we build if a downstream crate sets `--cfg=fuzzing`

Downstream crates building fur fuzzing will usually set
`--cfg=fuzzing` as a side-effect of the Rust fuzzing tooling. Thus,
we should ensure we build without failure in such cases.

We do this here by simply relying on the `_test_utils` feature,
rather than conditionally-compiling in modules based on the
`fuzzing` flag.

Document on claim events that amount_msat may be > invoice amount

Check UpdateAddHTLC::skimmed_fee_msat on receive

Make sure the penultimate hop took the amount of fee that they claimed to take.
Without checking this TLV, we're heavily relying on the receiving wallet code
to correctly implement logic to calculate that that the fee is as expected.

Set UpdateAddHTLC::skimmed_fee_msat on forward

So the receiver can verify it and approve underpaying HTLCs (see
ChannelConfig::accept_underpaying_htlcs).

Persist update_add sender skimmed fee in Channel

Track the sender's skimmed fee in UpdateAddHTLC

Allow receiving less than the onion claims to pay

Useful for penultimate hops in routes to take an extra fee, if for example they
opened a JIT channel to the payee and want them to help bear the channel open
cost.

Add PaymentClaimable::counterparty_skimmed_fee_msat

See its docs

Persist counterparty skimmed fee in ClaimableHTLC

Used to get an accurate skimmed fee in the resulting PaymentClaimable event.

Set extra skimmed fee on intercepted forward

Receivers need to use this value to verify incoming payments if
ChannelConfig::accept_underpaying_htlcs is set.

Add config knob for accepting underpaying HTLCs

See ChannelConfig::accept_underpaying_htlcs

Move next hop packet pubkey calculation to outside channel lock

Move PendingHTLCStatus construction inside channel lock

We need the channel lock for constructing a pending HTLC's status because we
need to know if the channel accepts underpaying HTLCs in upcoming commits.

Merge pull request #2120 from valentinewallace/2023-03-blinded-pathfinding

Merge pull request #2089 from wpaulino/bump-transaction-event-handler

Add BumpTransaction event handler

Provide a default CoinSelectionSource implementation via a new trait

Certain users may not care how their UTXOs are selected, or their wallet
may not expose enough controls to fully implement the
`CoinSelectionSource` trait. As an alternative, we introduce another
trait `WalletSource` they could opt to implement instead, which is much
simpler as it just returns the set of confirmed UTXOs that may be used.
This trait implementation is then consumed into a wrapper `Wallet` which
implements the `CoinSelectionSource` trait using a "smallest
above-dust-after-spend first" coin selection algorithm.

Add BumpTransaction event handler

This allows users to bump their commitments and HTLC transactions
without having to worry about all the little details to do so. Instead,
we'll just require that they implement the `CoinSelectionSource` trait
over their wallet/UTXO source, granting the event handler permission to
spend confirmed UTXOs for the transactions it'll produce.

While the event handler should in most cases produce valid transactions,
assuming the provided confirmed UTXOs are valid, it may not produce
relayable transactions due to not satisfying certain Replace-By-Fee
(RBF) mempool policy requirements. Some of these require that the
replacement transactions have a higher feerate and absolute fee than the
conflicting transactions it aims to replace. To make sure we adhere to
these requirements, we'd have to persist some state for all transactions
the event handler has produced, greatly increasing its complexity. While
we may consider implementing so in the future, we choose to go with a
simple initial version that relies on the OnchainTxHandler's bumping
frequency. For each new bumping attempt, the OnchainTxHandler proposes a
25% feerate increase to ensure transactions can propagate under
constrained mempool circumstances.

Expose ClaimId for each claim bump in BumpTransactionEvent

Expose existing PackageID to API and rename to ClaimId

In a future commit, we plan to expand `BumpTransactionEvent` variants to
include the unique identifier assigned to pending output claims by the
`OnchainTxHandler` when a commitment is broadcast/confirmed. This
requires making it public in our API. We also choose to rename it to
`ClaimId` for the benefit of users, as the previous `PackageID` term
could be interpreted to be the ID of a BIP-331 transaction package.