rust-lightning

Add LDK Node integration test

We add a simple workflow to our CI that runs `cargo check` on LDK Node to ensure
LDK didn't introduce breaking API changes.

The idea here is to catch breaking changes early, and encourage to fix
them in LDK or LDK Node `main` ASAP.

In the future we might want to extend this to run the full test suite,
once we whack-a-moled a few more of LDK Node's flaky tests.

Allow counterparty tx_abort before handling initial commitment signed

Upon processing the counterparty's initial `commitment_signed` for a
splice, we queue a monitor update with the new commitment transactions
spending the new funding transaction. Once handled, funding transaction
signatures can be exchanged and we must start monitoring the chain for a
possible commitment transaction broadcast spending the new funding
transaction. Aborting the splice negotiation then would therefore be
unsafe, hence why we currently force close in such cases. However, there
is no reason to force close prior to receiving their initial
`commitment_signed`, as this would imply the funding transaction
signatures have yet to be exchanged, thus making a commitment broadcast
spending said transaction impossible allowing us to abort the splice
negotiation safely.

Support capturing `tx_abort` send within channel reestablish tests

Provide the same docs in `ChangeDestinationSource` as the sync one

Copy async docs from async bump transaction objects to sync ones

When we added the async traits and wrapper structs for the
transaction-bumping logic, we didn't bother copying the
documentation to the sync wrappers as we figured the links
sufficed. Sadly, however, this means that our bindings logic will
have no docs but a broken link to an async object that doesn't
exist.

Instead, here, we copy the docs from the async objects to the sync
ones, at least leaving behind a comment noting that both need
updating whenever one gets updated.

We also fix one bogus link in `Wallet`'s docs.

Copy docs from `OutputSweeper` to `OutputSweeperSync`

When we added the async wrapper for `OutputSweeper`, we didn't
bother copying the documentation to the sync wrappers as we figured
the links sufficed. Sadly, however, this means that our bindings
logic will have no docs but a broken link to an async object that
doesn't exist.

Instead, here, we copy the docs from the async objects to the sync
ones, at least leaving behind a comment noting that both need
updating whenever one gets updated.

Copy async docs from async KVStore to sync one

When we added the async trait for `KVStore`, we didn't bother
copying the documentation to the sync wrappers as we figured the
links sufficed. Sadly, however, this means that our bindings logic
will have no docs but a broken link to an async object that doesn't
exist.

Instead, here, we copy the docs from the async objects to the sync
ones, at least leaving behind a comment noting that both need
updating whenever one gets updated.

`use` `Vec` from `alloc` rather than the crate prelude

This avoids confusing the bindings generator.

Copy no-export tags to new serialization traits

In 0.2 we added new `LengthLimitedRead` and `LengthReadable`
traits, but forgot to copy the no-export tags from the existing
`Read` and `Readable` traits. Here we add the missing tags.

Import `ChannelTransactionParameters` from its real path

Rather than importing `ChannelTransactionParameters` via the `use`
in `lightning::sign`, import it via its real path in
`lightning::sign::ecdsa`. This makes reading the code (incredibly
marginally) simpler, but also makes the bindings generator happy.

Mark async traits and structs no-export

We do not currently support async traits or methods in our
home-grown bindings logic, so here mark them no-export.

Require the high-level sign traits instead of `SignFn` in bindings

Methods like `StaticInvoice::sign` have their own signing-function
traits, so there's no actual need to use `SignFn` directly, its
just a useful generic wrapper. Sadly, because it uses `AsRef`
bounds, which aren't really practical to map in bindings, we can't
really expose it directly in bindings. Because there's an
alternative and its tricky to expose, we simply mark it no-export
here.

Mark `CheckedHrpstringError` instances as no-export

The details of these errors aren't particularly relevant, and its
not worth the effort of exporting them, so we just mark them
no-export here.

Mark BOLT 12 builders no-export in the new `OffersMessageFlow`

As move semantics do not map to bindings, the BOLT 12 object
builders are marked no-export. In the new `OffersMesageFlow`, here,
we also mark the methods which return these builders as no-export.

Don't prune `pending_requests` in `persist`

Previously, we would also prune any pending `GetInfo` or expired `Buy`
requests before we `persist`. This could have lead to races where we
drop a pending request and even remove the peer when calling `persist`.

Here, we simply split the pruning logic for the `pending_requests` and
expired JIT channel state, and only prune the latter before persisting.
This generally makes sense, as `pending_requests` isn't currently
persisted, so there is no need to prune before repersisting.

Both are however still pruned on peer disconnection.

`notify` `ChainMonitor`'s `EventNotifier` on async write completion

In c08476753f296319cd74c8394ff8cb6bb5a0e7b5 we a
`ChainMonitor::new_async_beta` and a corresponding
`MonitorUpdatingPersisterAsync` struct. To avoid circular
references, the `ChainMonitor` owns the
`MonitorUpdatingPersisterAsync` which uses a `FutureSpawner` to let
async writes happen in the background after it returns control flow
ownership to the `ChainMonitor`. This is great, except that because
`MonitorUpdatingPersisterAsync` thus doesn't have a reference to
the `ChainMonitor`, we have to poll for completion of the futures.

We do so in the new `Persist::get_and_clear_completed_updates` that
was added in the above-referenced commit. But on async monitor
write completion we're supposed to call `ChainMonitor`'s
`event_notifier.notify()` (ultimately waking up the background
processor which `await`s the corresponding update future). This
didn't happen in the new async flow.

Here we move `ChainMonitor`'s `event_notifier` into an `Arc` and
pass a reference to it through to the
`MonitorUpdatingPersisterAsync` which can then directly `notify()`
it and wake the background processor.

Persist fuzz corpus between CI runs

Implements a persistent, global fuzz corpus cache.

PRs perform a "read-only" restore from the `main` cache
to seed fuzzer runs. The `main` branch performs a
"read-write" to save new findings and grow the corpus.

Upload CI generated fuzz corpus coverage to codecov

Because each CI job runs on a fresh runner and can't share data
between jobs. We rely on Github Actions upload-artifact and
download-artifact to share the CI generated fuzz corpus, then
replay them in the `contrib/generate_fuzz_coverage.sh` script
to generate the coverage report.

Add draft release notes for 0.2

Add missing documentation for sigs-ready event to `splice_channel`

`ChannelManager::splice_channel` initiates a splice which
ultimately generates a series of events. The most important of
which, `FundingTransactionReadyForSigning` (which must always be
handled, unlike the others), was not documented.

Here we mention the event generation.

Add note in `OnionMessageIntercepted` to handle the connected event

Users implementing the "onion message mailbox" feature and handling
`OnionMessageIntercepted` events need to also handle
`Event::OnionMessagePeerConnected` events.

Here we update the event docs for both to add additional references
and be more explicit about what implementors need to do.

Drop useless `vec!` macro calls

`clippy` now complains about more instances of useless `vec!`s, so
we drop them here.

Replace `StateMachine::default` use with `core::mem::replace`

`clippy` now complains that `Default` for the interactive tx
constructor `StateMachine` can be auto-derived, but its a bit weird
to have a `Default` that loads an invalid ("indeterminate") state.
Instead, we replace the one line that actually cares about the
`Default` (which uses `core::mem::take`) with `core::mem::replace`,
making it more explict.

Add `readme` fields to most crates' `Cargo.toml`s

`crates.io` will show any README/README.md which apears in the
crate which is uploaded, but it doesn't consider the README from
the workspace, only if its in the crate itself.

Instead, add the `readme` field so that the workspace README also
gets uploaded.

Include monitor name in error when failing to load a monitor

If we fail to load a `ChannelMonitor` due to the new limits in LDK
0.2, its useful to communicate which monitor failed, which we do
here.

Requested at
https://github.com/lightningdevkit/rust-lightning/pull/4146#discussion_r2418136988