f Cleanup lock handling

f Account for `KVStore::read` returning a `Vec<u8>`

f Use sync_all rather than libc::fsync

As it iternally does the right thing (tm): call `libc::fsync` on
non-macOS UNIXes and `libc::fcntl` with `libc::F_FULLSYNC` set on macOS
(as Apple decided to break POSIX to cheat benchmarks).

f Use test-specific temp dir

... as otherwise we'll remove the entire temp dir on drop.

f Reuse `dest_file_path` as lock key

f Reintroduce per-write tmp files

f Better handling of `relative_path`

f Check `namespace`/`key` for control characters

... and use `PrintableString`

f Move empty-key checks before taking locks

Add `FilesystemStore`

We upstream the `FilesystemStore` implementation, which is backwards
compatible with `lightning-persister::FilesystemPersister`.

f Account for `KVStore::read` returning a `Vec<u8>`

Add `test_utils`

We add a utility function needed by upcoming `KVStore` implementation
tests.

Update `lightning-persister` crate

f Have `KVStore::read` return `Vec<u8>`

f Clarify `namespace`/`key` format requirments

Add `KVStore` interface trait

We upstream the `KVStore` interface trait from LDK Node, which will
replace `KVStorePersister` in the coming commits.

Besides persistence, `KVStore` implementations will also offer to `list`
keys present in a given `namespace` and `read` the stored values.

Merge pull request #2387 from vladimirfomene/add_extra_fields_to_ChannelClosed_event

Add counterparty_node_id & channel_capacity to ChannelClosed event

Merge pull request #2308 from alecchendev/2023-05-custom-htlc-tlvs

Add support for custom HTLC TLVs

Merge pull request #1789 from jkczyz/2022-10-scorer-decay

Smooth out channel liquidity bounds decay

Merge pull request #2481 from TheBlueMatt/2023-08-keysend-robust-test

Scope payment preimage in do_test_keysend_payments

Enforce explicit claims on payments with even custom TLVs

Because we don't know which custom TLV type numbers the user is
expecting (and it would be cumbersome for them to tell us), instead of
failing unknown even custom TLVs on deserialization, we accept all
custom TLVs, and pass them to the user to check whether they recognize
them and choose to fail back if they don't. However, a user may not
check for custom TLVs, in which case we should reject any even custom
TLVs as unknown.

This commit makes sure a user must explicitly accept a payment with
even custom TLVs, by (1) making the default
`ChannelManager::claim_funds` fail if the payment had even custom TLVs
and (2) adding a new function
`ChannelManager::claim_funds_with_known_custom_tlvs` that accepts them.

This commit also refactors our custom TLVs test and updates various
documentation to account for this.

Add `FailureCode::InvalidOnionPayload` variant

When a user decodes custom TLVs, if they fail to recognize even type
numbers they should fail back with the correct failure code and fail
data. This new variant adds the proper failure variant for the user to
pass into `ChannelManager::fail_htlc_backwards_with_reason`.

Note that the enum discriminants were removed because when adding a
struct variant we can no longer make use of the discriminant through
casting like we previously did, and instead have to manually define the
associated failure code anyway.

Drop non-matching custom TLVs when receiving MPP

Upon receiving multiple payment parts with custom TLVs, we fail payments
if they have any non-matching or missing even TLVs, and otherwise just
drop non-matching TLVs if they're odd.

Handle receiving custom HTLC TLVs

This completes basic receiver-side support for custom TLVs and adds
functional testing for sending and receiving.

De/serialize custom TLVs on `{Inbound,Outbound}OnionPayload`

When serialized, the TLVs in `OutboundOnionPayload`, unlike a normal
TLV stream, are prefixed with the length of the stream. To allow a user
to add arbitrary custom TLVs, we aren't able to communicate to our
serialization macros exactly which fields to expect, so this commit
adds new macro variants to allow appending an extra set of bytes (and
modifying the prefixed length accordingly).

Because the keysend preimage TLV has a type number in the custom type
range, and a user's TLVs may have type numbers above and/or below
keysend's type number, and because TLV streams must be serialized in
increasing order by type number, this commit also ensures the keysend
TLV is properly sorted/serialized amongst the custom TLVs.

Add custom tlvs to `PendingOutboundPayment::Retryable`

Allow users to provide custom TLVs through `RecipientOnionFields`

Custom TLVs allow users to send extra application-specific data with
a payment. These have the additional flexibility compared to
`payment_metadata` that they don't have to reflect recipient generated
data provided in an invoice, in which `payment_metadata` could be
reused.

We ensure provided type numbers are unique, increasing, and within the
experimental range with the `RecipientOnionFields::with_custom_tlvs`
method.

This begins sender-side support for custom TLVs.

Merge pull request #2128 from valentinewallace/2023-03-route-blinding-groundwork

Route blinding groundwork

Smooth out channel liquidity bounds decay

Decaying the channel liquidity bounds by a half life can result in a
large decrease, which may have an oscillating affect on whether a
channel is retried. Approximate an additional three-quarter life when
half of the next half life has passed to help smooth out the decay.

Add test coverage ChannelClosed event fields

Add counterparty_node_id & channel_capacity to ChannelClosed

The current ChannelClosed event does not let
you know the counterparty during a channel close
event. This change adds the counterparty_node_id
and the channel_capacity to the ChannelClosed event.
This helps users to have more context during a
channel close event. Solves #2343

Make CI build -> test flows test -> build.

Doing `cargo test` causes us to build both the crate(s) themselves
and the test binaries, which depend on the main builds. However, it
can start building the test code while the actual program code for
the main crate(s) themselves are being built, making a
build -> test flow slightly slower than test -> build.

Its not really a huge deal, but I'm using `ci/ci-tests.sh` more
locally and it meaningfully changes the time-to-test-run.

Scope payment preimage in do_test_keysend_payments

b0d4ab8cf8c93740674a00546be38a1a5f0a83c3 fixed a nasty bug where
we'd failed to include the payment preimage in keysend onions at
all. Ultimately, this was a test failure - the existing test suite
should which did keysend payments were not structured in a way that
would fail in this case, instead using the same preimage variable
both for sending and receiving.

Here we improve the main keysend test tweaked by b0d4ab8cf8c9374067
to make absolutely sure it cannot work if the preimage doesn't come
from the onion. We make the payment preimage on the sending side a
variable inside a scope which only exists for the send call. Once
that scope completes the payment preimage only exists in the
sending `ChannelManager`, which must have put it in the onion in
order for the receiving node to have it.

Merge pull request #2475 from alecchendev/2023-08-actually-fix-keysend

Fix keysend not being sent in `OutboundPayment::send_payment_internal`

Send keysend preimage through OutboundPayment::send_payment_internal

Fixes a bug where we wouldn't use the provided keysend preimage when
piping through OutboundPayment::pay_route_internal.

Also simplifies and refactors existing keysend tests to make sure this
gets hit.

Move keysend tests to payment_tests.rs

Remove unnecessary vecs in channel.rs

Replace OnionHopData with OutboundPayload for outbound onions

Follows on from the previous commit, see its message

Receive payment onions as new InboundPayload instead of OnionHopData

To support route blinding, we want to split OnionHopData into two separate
structs, one for inbound onions and one for outbound onions. This is because
blinded payloads change the fields present in the onion hop data struct based
on whether we're sending vs receiving (outbound onions include encrypted blobs,
inbound onions can decrypt those blobs and contain the decrypted fields
themselves).

In upcoming commits, we'll add variants for blinded payloads to the new
InboundPayload enum.

Remove outdated documentation of a panic

Remove indentation in payment receive util

This also set us up for supporting receiving blinded onion payloads.

Merge pull request #2366 from valentinewallace/2023-05-blinded-pathfinding-fuzz

Blinded pathfinding fuzzing

Merge pull request #2460 from TheBlueMatt/2023-07-claimable-clarify

Rename `Balance::claimable_amount_satoshis` to have a unique name

Merge pull request #2463 from TheBlueMatt/2023-07-no-rustdoc-unicode

Drop unicode in documentation

Merge pull request #2465 from alecchendev/2023-07-flip-keysend-feature-bit

Flip keysend feature bit on

Merge pull request #2454 from optout21/unused-use

(Minor) Remove an unused import (ChannelSigner)

Merge pull request #2459 from valentinewallace/2023-07-reconnect-peers-test-util

Struct-ify `reconnect_nodes` test util args

Flip keysend feature bit in node features

Drop unicode in documentation

Javadocs refuse unicode and as our rustdocs get copied over to Java
bindings (and thus get run through javadocs) we can't have unicode
in our rustdocs.

Drop `claimable` from `Balance::claimable_amount_satoshis` fields

In Java/TypeScript, we map enums as a base class and each variant
as a class which extends the base. In Java/TypeScript, functions
and fields share the same namespace, which means we cannot have
functions on an enum which have the same name as any fields in any
enum variants.

`Balance`'s `claimable_amount_satoshis` method aliases with fields
in each variant, and thus ultimately doesn't compile in TypeScript.

Because `Balance::claimable_amount_satoshis` has the same name as
the fields, it's also a bit confusing, as it doesn't return the
field for each variant, but sometimes returns zero if we're not
sure we can claim the balance.

Instead, we rename the fields in each enum variant to simply
`amount_satoshis`, to avoid implying that we can definitely claim
the balance.

Struct-ify reconnect_nodes test util args

Makes it easier to add new arguments without a ton of resulting test changes.
Useful for route blinding testing because we need to check for malformed HTLCs,
which is not currently supported by reconnect_nodes. It also makes it easier to
tell what is being checked in relevant tests.

Merge pull request #2104 from douglaz/docs_fixes_channel

Docs improvements for channel

Remove an unused use (ChannelSigner)

Fuzz test blinded payment pathfinding

Router fuzz: macroize first/last hops construction and pathfinding call

For reuse in fuzzing blinded payment pathfinding, and to ensure fuzz input
values are fetched in the same order in both match arms.

Docs improvements for channel

Merge pull request #2446 from TheBlueMatt/2023-07-ci-more-test

Run all tests first before testing more esoteric flags in CI

Merge pull request #2448 from TheBlueMatt/2023-07-cm-clone

Impl clone for ChannelMonitor

Merge pull request #2370 from valentinewallace/2023-06-send-along-path-args

Update `send_payment_along_path` to take its args as struct

Impl clone for ChannelMonitor

This gives people more freedom with the channel monitors. For Mutiny
this would be nice for us to be able to create copies of them and pass
aorund in memory without having to serialize until we actually want to.

Originally by benthecarman <benthecarman@live.com>
Small bugfix from Matt Corallo <git@bluematt.me>

Run all tests first before testing more esoteric flags in CI

This should at least marginally more aggressively target things
which are more likely to have changed in CI, making `ci-tests.sh`
more useful as a "default" script for developers to run locally.

Merge pull request #2431 from arik-so/2023-07-public-excess-data

Merge pull request #2444 from szabgab/https

http => https

http => https

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

Release 0.0.116

Bump crate versions to 0.0.116 release

Add a warning on anchors and update 116 changelog for release

Add `lightning-background-processor` `no-std` feature

While this is generally uneccessary as users set the `no-std` or
`std` features on the `lightning` crate directly, having this
allows `lightning-background-processor` to be built by itself
without extra dep lines. Specifically, the bindings are moving to
using the `-Z avoid-dev-deps` option, which now causes
`lightning-background-processor` to fail to build directly.

Merge pull request #2436 from tnull/2023-07-improve-router-logging

Improve router logging and update documentation

Merge pull request #2439 from tnull/2023-05-fix-0conf-sigs-racing-confirms

Avoid panic when 0conf channel's ann. sigs race on-chain confirmation

Improve logging for ignored candiate hops

Previously, we barely gave any hints why we excluded certain hops during
pathfinding. Here, we introduce more verbose logging by a) accounting
how much candidates we ignored for which reasons and b) logging any
first/last/blinded hops we end up ignoring.

Fixes #1646.

Update outdated `router.rs` docs

As `RouteParameters` are not included anymore in
`Event::PaymentPathFailed` since 0.0.115, and we don't give value/payee
as immediate arguments to `find_route` anymore.

Merge pull request #2434 from TheBlueMatt/2023-07-116-bindings-part-2

0.0.116 Bindings Changes

Avoid `unwrap`ing in `get_announcement_sigs`

While this is currently not reachable, it's still cleaner to
avoid the `unwrap` and return `None` if `short_channel_id` hasn't been
set yet.

Avoid panic when 0conf channel's ann. sigs race on-chain confirmation

A channel's `short_channel_id` is currently only set when the funding
transaction is confirmed via `transactions_confirmed`, which might be
well after the channel initally becomes usable, e.g., in the 0conf case.

Previously we would panic due to a reachable `unwrap` when receiving a
counterparty's `announcement_signatures` message for a 0conf channel
pending confirmation on-chain.

Here we fix this bug by avoiding unsafe `unwrap`s and just erroring out
and ignoring the announcement_signatures message if the `short_channel_id`
hasn't been set yet.

Add relevant derives for `BigSize` as its a simple integer

Add relevant trait derives for `bump_transaction` structs

Notably including `Hash`/`Eq`/`Ord` for structs which may be used
in maps.

Make `OffersMessage` and offers errors `Clone`able

Make `requires_unknown_bits_from` param type bindings compatible

While bindings should probably be able to figure out that this is
the same type as `Self`, for now we simply swap the type to make
the bindings generator have an easier go of it.

Mark the `Duration` serialization implementation no-bindings-export

The bindings are being updated to consider all traits even if the
trait itself is no-export, which causes issues generating code
around the `Duration` impl here.

No-export un-exportable types in BOLT12 module

We missed one method that now cannot be bindings exported - the
`payment_paths` method, as it returns a slice of objects, which
cannot be supported in bindings.

No-export `APeerManager` in bindings

`APeerManager` will simply be mapped as `PeerManager` in bindings,
as structs are all concretized into a single form.

Move `ClaimId` to `[u8; 32]` in bindings.

This matches what we've done for other `[u8; 32]` newtypes.

Tweak PSBT signing for bindings compatibility

In bindings we can't practically pass a mutable PSBT, and instead
need to pass an owned transaction and have the sign method return a
signed copy. We do this here for all build modes as its not a
material API change for Rust users.

Add a c_bindings test to `check-compiles.sh` as it should build

Merge pull request #2430 from TheBlueMatt/2023-07-116-bindings-part-1

Assorted 0.0.116 Bindings updates

Merge pull request #2382 from dunxen/2077-followups

Address outstanding 2077 feedback

Drop `c_bindings` implementation of scoring on `Mutex`/`RefCell`

This code was always effectively dead - we have a special
`MultiThreadedLockableScore` type which wraps a `Mutex` for
bindings users, so there's no need to implement any
bindings-specific scoring logic for them.

Pass `InFlightHltcs` to the scorer by ownership rather than ref

Given we build `InFlightHtlcs` per route-fetch call, there's no
reason to pass them out by reference rather than simply giving the
user the full object. This also allows them to tweak the in-flight
set before fetching a route.

Pass must-spend inputs to users by ownership

We already hold them in a vec, so there's no cost to passing them
by ownership vs making it a slice. Further, this helps bindings as
we can't represent slices to non-pointers in a sensible way.

Tweak transaction bumping `sign_tx` types for bindings

In bindings we can't practically pass a mutable transaction, and
instead need to pass an owned transaction and have the sign method
return a signed copy. We do this here for all build modes as the
API is roughly equivalent also to Rust users.

Publicize UnsignedChannelAnnouncement's excess_data.

Making the `excess_data` field public significantly
simplifies writing legible unit tests for the
Rapid Gossip Sync Server.

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