Merge pull request #2382 from dunxen/2077-followups

Address outstanding 2077 feedback

Merge pull request #2423 from wpaulino/2403-fixups

PR #2403 fixups

Close and remove unfunded inbound/outbound channels that are older than an hour

We introduce a `UnfundedChannelContext` which contains a counter for the
current age of an unfunded channel in timer ticks. This age is incremented
for every `ChannelManager::timer_tick_ocurred` and the unfunded channel
is removed if it exceeds `UNFUNDED_CHANNEL_AGE_LIMIT_TICKS`.

The value will not be persisted as unfunded channels themselves are not
persisted.

Remove redundant 'outbound' wording from methods

Force close pending channels in `internal_shutdown`

Consider all channel maps in `update_partial_channel_config`

Fallback `close_channel_internal` to force close unfunded channels

Add missing unfunded channel maps checks in `ChannelManager`

One of a series of follow-up commits to address some issues found
in PR 2077, where we split channels up into different maps and structs
depending on phase in their life.

Refer to channels busy with funding tx negotiation as "unfunded"

We had some inconsistencies so far in referring to channels such as
`OutboundV1Channel` and `InboundV1Channel` as pending and unfunded.
From here we refer to these kinds of channels only as "unfunded".

This is a slight conflation with the term "unfunded" in the contexts
of denial of service mitigation. There, "unfunded" actually refers to
non-0conf, inbound channels that have not had their funding transaction
confirmed. This might warrant changing that usage to "unconfirmed inbound".

Merge pull request #2426 from TheBlueMatt/2023-07-proc-macro2-msrv

Only try to build `lightning-transaction-sync` if we meet its MSRV

This should fix CI

Pin `proc-macro2` in CI to fix MSRV breakage

The proc-macro2 crate switched to Rust edition 2021 starting with
v1.0.66, i.e., has MSRV of 1.56.

Here, we pin it in CI to fix the breakage.

Test MSRV builds (without dev-dependencies) in CI

Drop `tokio/macros` dependency in `lightning-net-tokio`, fix MSRV

The `tokio` `macros` feature depends on `proc-macro2`, which
recently broke its MSRV in a patch version. Such crates aren't
reasonable for us to have as dependencies, so instead we replace
the one trivial use we have of `tokio::select!()` with our own
manual future.

Add warning regarding remote fee estimators

Merge pull request #2414 from TheBlueMatt/2023-07-cut-116-rc

Add 0.0.116 CHANGELOG entries and prep for 0.0.116rc1

Update version numbers to rc1, from alpha1

Add 0.0.116rc1 CHANGELOG entries (to be renamed 116 later)

Merge pull request #2415 from wpaulino/update-fee-anchors

Add min mempool estimate for feerate updates on anchor channels

Clarify log for commitment transaction already meeting required feerate

Drop use of RefCell in DebugIter

The `RefCell` was necessary in a previous iteration of the code in which
the iterator was not `Clone` so we needed interior mutability in order
to consume the iterator. Now that it is `Clone`, we can drop it, as
we're no longer mutating the original iterator.

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

Integrate BumpTransactionEventHandler into existing anchor tests

Merge pull request #2416 from jkczyz/2023-07-invoice-rename

Qualify BOLT 11/12 invoice and related types

Use min mempool feerate for outbound updates on anchor channels

As done with inbound feerate updates, we can afford to commit less in
fees, as long as we still may the minimum mempool feerate. This enables
users to spend a bit more of their balance, as less funds are being
committed to transaction fees.

Relax constraints for inbound feerate updates on anchor channels

Channels supporting anchors outputs no longer require their feerate
updates to target a prompt confirmation since commitment transactions
can be bumped when broadcasting. Commitment transactions must now at
least meet the minimum mempool feerate, until package relay is deployed,
such that they can propagate across node mempools in the network by
themselves.

The existing higher bound no longer applies to channels supporting
anchor outputs since their HTLC transactions don't have any fees
committed, which directly impact the available balance users can send.

Add new ConfirmationTarget variant for min mempool feerates

Now that we support channels with anchor outputs, we add a new
ConfirmationTarget variant that, for now, will only apply to such
channels. This new variant should target estimating the minimum feerate
required to be accepted into most node mempools across the network.

Integrate BumpTransactionEventHandler into existing anchor tests

Add BumpTransactionEventHandler instance to node test harness

Improve logging in BumpTransactionEventHandler paths

Add log_iter utility macro

This is a useful primitive to have that formats the contents of the
iterator as a comma-separated list.

Add debug assertions for weight estimates of bump transactions

This ensures our estimates are correct by never underestimating and
only allowing overestimations by a margin of 1%.

Consider existing commitment transaction feerate when bumping

With anchors, we've yet to change the frequency or aggressiveness of
feerate updates, so it's likely that commitment transactions have a
good enough feerate to confirm on its own. In any case, when producing a
child anchor transaction, we should already take into account the fees
paid by the commitment transaction itself, allowing the user to save
some satoshis. Unfortunately, in its current form, this will still
result in overpaying by a small margin at the expense of making the coin
selection API more complex.

Avoid yielding ChannelClose bump events with sufficient feerate

There's no need to yield such an event when the commitment transaction
already meets the target feerate on its own, so we can simply broadcast
it without an anchor child transaction. This may be a common occurrence
until we are less aggressive about feerate updates.

Move feerate helpers to chain module

We plan to use these outside of the `bump_transaction` module in the
next commit, and they really should belong in the same module as
`FeeEstimator`.

Qualify the BOLT 11 invoice description type

A previous commit qualified the BOLT 11 invoice type, so any related
types should be similarly qualified, if public.

Qualify the BOLT 11 invoice signature type

A previous commit qualified the BOLT 11 invoice type, so any related
types should be similarly qualified, if public.

Qualify the BOLT 11 invoice features type

A previous commit qualified the BOLT 11 invoice type, so any related
types should be similarly qualified, if public.

Qualify the BOLT 11 semantic error type

A previous commit qualified the BOLT 12 semantic error type. Qualify the
BOLT 11 semantic error type for consistency.

Qualify the BOLT 11 parse error type

A previous commit qualified the BOLT 12 parse error type. Qualify the
BOLT 11 parse error type for consistency.

Qualify the BOLT 11 raw invoice types

A previous commit qualified the BOLT 11 invoice type, so any related
types should be similarly qualified, if public.

Qualify the BOLT 11 invoice type

A previous commit qualified the BOLT 12 invoice type. Qualify the BOLT
11 invoice type for consistency.

Qualify the BOLT 12 semantic error

To avoid a naming conflict in bindings with BOLT 11 semantic error,
qualify the BOLT 12 semantic error type.

Qualify the BOLT 12 parse error

To avoid a naming conflict in bindings with BOLT 11 parse error, qualify
the BOLT 12 parse error type.

Qualify the BOLT 12 unsigned invoice type

A previous commit qualified the BOLT 12 invoice type, so any related
types should be similarly qualified, if public.

Qualify the BOLT 12 invoice type

To avoid a naming conflict in bindings with BOLT 11 invoices, qualify
the BOLT 12 invoice type.

Fix grammar in docs

Use rustc stable for check_commits

Otherwise, the compiler will panic when using 1.57 for upcoming commits.

Merge pull request #2391 from TheBlueMatt/2023-07-all-compl-actions

Handle pre-startup and closed-channel monitor update completion actions

Add comment describing when a completion action can be discarded

In an older PR a reviewer had asked why the discarding of a channel
being blocked on another monitor update is okay if the blocked
channel has since closed. At the time, this was not actually okay -
the monitor updates in the channel weren't moved to the
`ChannelManager` on close so the whole pipeline was busted, but
with the changes in 4041f0899f86eaf6a0a4576a91918fa54026ac46 the
handling of channel closes with pending monitor updates is now
correct, and so is the existing code block.

Run monitor update completion actions for pre-startup completion

If a `ChannelMonitorUpdate` completes being persisted, but the
`ChannelManager` isn't informed thereof (or isn't persisted) before
shutdown, on startup we may still have it listed as in-flight. When
we compare the available `ChannelMonitor` with the in-flight set,
we'll notice it completed and remove it, however this may leave
some post-update actions dangling which need to complete.

Here we handle this with a new `BackgroundEvent` indicating we need
to handle any post-update action(s) for a given channel.

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

Bump transaction event handler fixups

Merge pull request #2406 from tnull/2023-07-pin-serde

Pin `serde_json` in CI to fix MSRV builds

Pin `serde_json` in CI to fix MSRV

Unfortunately `serde_json` switched to use Rust edition 2021 with
version 1.0.101, i.e., has an MSRV of 1.56 now.

Expose previous UTXO for anchor and HTLC inputs

This may be required by some wallets that rely on PSBTs internally to
create/sign transactions.

Add transaction-related helpers to AnchorDescriptor

This provides a similar interface as `HTLCDescriptor` for users which
choose to implement their own bump transaction event handler.

Provide missing post-derivation signer parameters

Users may expect these to be provided manually after derivation in the
event they need to perform any enforcement prior to signing.

Cache HTLC per_commitment_point in descriptor

This allows us to obtain the HTLC input and output from its descriptor
without needing to derive the `per_commitment_point` through the signer.

Expose CoinSelection struct members

These are meant to be provided by the user, so they need to be exposed
in the API.

Accept BumpTransactionEvent in handle_event

There's no reason to accept the general `Event` enum.

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

Handle monitor completion actions for closed channels

If a channel has been closed, there may still be some
`ChannelMonitorUpdate`(s) which are pending completion. These
in-flight updates may also be blocking another channel from letting
an update fly, e.g. for forwarded payments where the payment
preimage will be removed from the downstream channel after the
upstream channel has closed.

Luckily all the infrastructure to handle this case is already in
place - we just need to process the
`monitor_update_blocked_actions` for closed channels.

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.