Support signing BOLT 12 invoices in NodeSigner

BOLT 12 messages need to be signed in the following scenarios:
- constructing an InvoiceRequest after scanning an Offer,
- constructing an Invoice after scanning a Refund, and
- constructing an Invoice when handling an InvoiceRequest.

Extend the NodeSigner trait to support signing BOLT 12 invoices such
that it can be used in the latter contexts. The method could be used
in an OffersMessageHandler.

Use TaggedHash in merkle::verify_signature

An earlier commit introduced TaggedHash for use in sign_message. For
consistency, use it in verify_signature, too.

Expose Offer/InvoiceRequest methods in Invoice

Bolt12Invoice can either be for an Offer (via an InvoiceRequest) or a
Refund. It wraps those types, so expose their methods on both
Bolt12Invoice and UnsignedBolt12Invoice.

Since Refund does not have all the Offer/InvoiceRequest methods, use an
Option return type such that None can returned for refund-based
invoices.

For methods that are duplicated between Offer/InvoiceRequest and
Bolt12Invoice, prefer the (non-Option, if applicable) method from
Bolt12Invoice (e.g., amount_msats, signing_pubkey).

Expose invoice accessors in UnsignedBolt12Invoice

Expose Offer accessor functions in InvoiceRequest

Also, expose both Offer and InvoiceRequest functions in
UnsignedInvoiceRequest.

Macro-ize InvoiceRequest accessors for reuse

Various messages wrap InvoiceRequestContents, which shouldn't be exposed
as it is an implementation detail. Define a macro for InvoiceRequest
accessor methods so that these messages can also define them.

Macro-ize Offer accessors for reuse

InvoiceRequest wraps OfferContents, which shouldn't be exposed as it is
an implementation detail. Define a macro for Offer accessor methods so
that InvoiceRequest and UnsignedInvoiceRequest can also define them.

Move BOLT 12 invoice method implementations

Move BOLT 12 InvoiceRequest method implementations

Move BOLT 12 offer method implementations

Unsigned BOLT 12 message parsing and serialization

Rename field of unsigned BOLT message contents

Using `contents` for the field name is more consistent with the signed
messages.

Wrap KeyPair by DerivedSigningPubkey

InvoiceBuilder is parameterized by a SigningPubkeyStrategy, either
ExplicitSigningPubkey and DerivedSigningPubkey. It also holds an
Option<KeyPair>, which may be None and Some for those strategies,
respectively. This leads to methods for InvoiceBuilder parameterized by
DerivedSigningPubkey needing to blindly unwrap the Option<KeyPair>.
Instead, have DerivedSigningPubkey wrap KeyPair.

TaggedHash for BOLT 12 signing function

The function used to sign BOLT 12 messages only takes a message digest.
This doesn't allow signers to independently verify the message before
signing nor does it allow them to derive the necessary signing keys, if
needed.

Introduce a TaggedHash wrapper for a message digest, which each unsigned
BOLT 12 message type constructs upon initialization. Change the signing
function to take AsRef<TaggedHash>, which each unsigned type implements.
This allows the signing function to take any unsigned message and obtain
its tagged hash.

Make offers::merkle::SignError visible

Tidy up bitcoin::secp256k1 imports

Merge pull request #2104 from douglaz/docs_fixes_channel

Docs improvements for channel

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

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

Tweak generics on `derive_channel_signer` to be bindings-compatible

The C bindings generation currently has issues looking through a
generic associated type. While this should be fixed in the bindings
generator, its easy to fix here for now and we can revisit it
later.

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