Fix inbound capacity comment

We add a `Node::start_with_runtime` method that allows to reuse a
pre-existing runtime, e.g., to avoid stacking runtime contexts when
running in a tokio async environment.

This reverts commit 0285b55.

…-uniffi-target-folder

Ignore all `target` folders including bindings

…tart-with-runtime

Allow start from outer runtime

Fix `cc` msrv

This reverts commit abfcc2e.

Revert "Pin `cc` to `1.0.105` for MSRV"

* Add `UnifiedQrPayment` module for BIP21 URIs

Firstly, I thought I staged and made commits for `unified_qr.rs`
so sorry if this is out of order!

But in `unified_qr.rs` I
  - I introduced the `UnifiedQrPayment` struct to handle creating
    and paying BIP21 URIs
  - `receive` generates a URI with an on-chain address and BOLT11
     invoice and returns the URI as a string
  - `send` will parse a given URI string and attempt to send the
    BOLT12 offer, BOLT11 invoice, then if those fail the fallback
    on-chain address will be paid to.
  - Then I included tests for URI generation and URI parsing
  - Also has logging and error handling for payment operations

* Add `unified_qr_payment` payment handler to `Node`

  - implement unified_qr_payment method to create the
    Unified QR  payment handler
  - Includes conditional UniFFI features and updates docs
    with BIP21 and BOLT11 links

* Add support for `unified_qr` in payment mod

  - Included unified_qr in payment module
  - Added `PaymentResult` and `UnifiedQrPayment`
    from unified_qr for public use

* Add bip21 crate to handle BIP21 URIs

* Add `UnifiedQrPayment` and `PaymentResult` to `ldk_node.udl`

  - Introduced `UnifiedQrPayment` method to `Node` interface
  - Add `UnifiedQrPayment` interface with `receieve and
    `send` methods
  - Add `PaymentResult` interface (enum) with `Onchain`,
    `Bolt11` and `Bolt12` fields

These changes add support for our UniFFI bindings and enable
the use of `unified_qr_payment` payment handler in Swift,
and Kotlin.

* Update `Error` enum with URI related errors

  - Add `UriParameterFailed` and `InvalidUri` fields to
    the `Error` enum
  - Added related error  messages in the Display impl for
    the new fields

* Add `PaymentResult` import for UniFFI bindings

  - Added `PaymentResult` so the .udl could access
    the enum
  - Added comment to explain the need to import any
    re-exported items to enure they're accessible in
    UniFFI. (becasue rustc says to add them in `lib.rs`

* Add Unified QR `send`/`receive` integration tests

  - Added `unified_qr_send_receive` test to verify the `UnifedQrPayment`
    functionality
  - Added logic to handle paying a `BOLT12` offer, `BOLT11` invoice,
    and if those fail `On-chain` tx from a URI.
  - Validated each payments successful event
  - Ensured the off-chain and on-chain balacnes reflected the payment
    attempts

* Update PR with optimizations and nit fixups

The changes include:
  - Fixed a handful of nits for better readability in
    docs and simple grammar errors and made various name
    changes that affected the committed files.
  - Added a helper function in unified_qr.rs called
    capitalize_qr_params to format the lightning param in
    the receive method
  - Removed the optional message in the receive method and
    made it a required &str
  - Adjusted UDL formatting to use tabs instead of spaces

These changes were made to improve code quality and
maintainability based on the review feedback

* Refactor URI parsing and add Bolt12 offer in receive

Changes include:
  - Modified serialize_params to serialize both invoices and offers
  - Refactored deserialize_temp by removing the code that was
    parsing based on the lightning invoice/offer prefix. I instead
    used for loop to iterate over each lightning parameter,
    attempting to parse the string as an offer first, and then as an
    invoice. May need to log an error if neither succeeds
  - Added support for Bolt12 offers in the receive method
  - Updated capitalize_params function to handle multiple lightning
    parameters
  - Added a generate_bip21_uri test to show what the uri looks
    like in integration_tests_rust
  - Adjusted integration tests. Still needs work

Still trying to figure out a bug related to Bolt12 offers being
"paid" when it should fall back to an on-chain tx

* Update BOLT12 offer to use `lno` key

In this commit:
  - In serialize_params, BOLT12 offers were changed
    to be serialized with the `lno` key rather than
    the `lightning` key
  - During deserializing, I had to make the same update.
    Used a match to check whether it was a `lightning`
    or `lno` key and then parsed accordingly.
  - Next, a small name change: capitalize_qr_params to
    format_uri. Previously I changed the value after
    "&lightning" to all caps, but the "&lno=" value
    wasn't being changed. So, added a helper method inside
    format_uri to capitalize the values given the key!
  - Updated corresponding tests with `lno` update

Small nits:
  - Updated QrPaymentResult with more thorough docs
  - Added a parsing test with an offer

* Refactor for clarity and improve error handling

This commit fixes a handful of minor comments/nits
that include:
  - Updates to set the `bip21`  crates default-features to false,
    to minimize dependencies.
  - Enable the `std` feature since we use/benefit from it.

  - In `receive` return `InvoiceCreationFailed` or `OfferCreationFailed`
    when creating an invoice or offer. Rather than silently logging the
    error.
  - Also in `receive` we first check if an amount is specified, and if
    not, return an error and abort.
  - Pass in `Config` to `UnifiedQrPayment` struct to use the users config
    network.
  - In `send` instead of checking each network for the `NetworkChecked`
    URI, we pass in the `Config::Network`.
  - Simplifed param parsing in `deserialize_temp` by directly finding
    the key and parsing the corresponding value.

  - General documentation fixes.
  - In parsing tests, moved longer invoice/offer strings into.
    variables that start with expected_ for clarity.

* Fix docs for clarity

Cleaned up the docs so they are easier to understand for the
user. Also changed the message param in receive to description.

.. rather than once per target.

Recently, Rust 1.80 introduced automatic checking of `cfg` flags (see
https://blog.rust-lang.org/2024/05/06/check-cfg.html). Here,
we add all custom `cfg`s to the expected list

…-check-cfg

Account for `check-cfg`

…-payment-variable-naming-bindings

…s-once

…-test-cfg

Fix: added `cfg(cln_test)` to `Cargo.toml`

Pin `tokio` to v1.38.1 to fix MSRV build

…oads

Enable caching for `bitcoind`/`electrs` in CI

.. just to be sure.

…os-specific

Make cache `key`s OS-specific

... see if dropping $HOME works.

…hing

Try fix caching

.. since it stopped working now?

…hing-2

Try fixing caching once more

.. we previously only set the environment variables when we downloaded
the binaries. Here, we set them in a separate step to have them being
usable when we're hitting the cache

…hing-3

Fix caching third attempt

Add support for including `payer_note` in `Bolt12Offer`
and `PaymentKind::Bolt12` and updated the relevant code to
handle where the new `payer_note` field was required.

…payer_note-in-PKbolt12

Expose `payer_note` in `PaymentKind::Bolt12`

.. somehow this was previously overlooked.

`SendingParameters` allows users to override opinionated values while
routing a payment such as `max_total_routing_fees`, `max_path_count`
`max_total_cltv_delta`, and `max_channel_saturation_power_of_half`

Updated docs for `max_channel_saturation_power_of_half` for
clarity.

Introduced `sending_parameters_config` to `Config` for node-wide
routing and pathfinding configuration. Also, added default values
for `SendingParameters` to ensure reasonable defaults when no
custom settings are provided by the user.

Updated `Bolt11Payment` `send` method to accept `SendingParameters`,
as a parameter. If the user provided sending params the default
values are overridden.

Added the optional `SendingParameters` to `send_using_amount` in
`Bolt11Payment`. If the user provides sending params the values
will be overridden otherwise they'll use the default values.

Added optional SendingParameters to the send method in
SpontaneousPayment. If the user provides sending params
the values will be overridden otherwise they remain the
same.

…ce-PaymentParameters

Add `SendingParameters` struct for customizable payments

Previously, the `SendingParamters` field was simply an `Option<u64>`,
which however means we could just override it to be `Some`. Here, we
have it be `Option<Option<u64>>` which allows the `None` override. As
UniFFI doesn't support `Option<Option<..>>`, we work around this via a
dedicated `enum` that is only exposed under the `uniffi` feature.

.. as it was used for spontaneous payments only and hence a bit
misleading.

We drop it for now and see if any users would complain. If so, it would
probably be sufficient for it to be an optional parameter on the
spontaneous payments methods.

Previously, we chose to expose `ChannelConfig` as a Uniffi `interface`,
providing accessor methods. Unfortunately this forced us to `Arc` it
everywhere in the API, and also didn't allow to retrieve the currently
set dust exposure limits. Here, we refactor our version of
`ChannelConfig` to be a normal `struct` (Uniffi `dictionary`), and only
expose the `MaxDustHTLCExposure` as an enum-`interface`.

lightningdevkit#336 followups

…fig-refactor

Refactor `ChannelConfig` / `MaxDustHTLCExposure`

.. previously we used LDK's `FeeEstimator` and `ConfirmationTarget` and
~misused some of the latter's variants for our non-Lightning operations.

Here, we introduce our own `FeeEstimator` and `ConfirmationTarget`
allowing to add specific variants for `ChannelFunding` and
`OnchainPayment`s, for example.

…or-refactor

Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 3 to 4.1.7.
- [Release notes](https://github.com/actions/download-artifact/releases)
- [Commits](actions/download-artifact@v3...v4.1.7)

---
updated-dependencies:
- dependency-name: actions/download-artifact
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

…t/github_actions/dot-github/workflows/actions/download-artifact-4.1.7

Bump actions/download-artifact from 3 to 4.1.7 in /.github/workflows

Previously, only a few files included coypright headers. Here, we fix
the omission and add the headers to all files where they were absent.

…ht-headers

Add copyright notices where they were missing

Vss-client upgrade to 0.3.x

What this commit does:
Implements a method `set_node_alias` on NodeBuilder to allow
callers customize/set the value of the node alias. This method
sanitizes the user-provided alias by ensuring the following:
 + Node alias is UTF-8-encoded String
 + Node alias is non-empty
 + Node alias cannot exceed 32 bytes
 + Node alias is only valid up to the first null byte. Every
   character after the null byte is discraded

Additionally, a test case is provided to cover sanitizing
empty node alias, as well as an alias with emojis (copied and
modified from rust-lightning) and a sandwiched null byte.

What this commit does:
Broadcasts node announcement with the user-provided alias, if set,
else, uses the default [0u8;32].

Additionally, adds a random node alias generating function for use
in the generation of random configuration.

     alias sanitization

- Skips broadcasting node announcement in the event that either
  the node alias or the listening addresses are not set.
- Aligns the InvalidNodeAlias error variant with the others to
  make it work with language bindings.
- Simplifies the method to set the node alias.
- Cleans up the alias sanitizing function to ensure that protocol-
  compliant aliases (in this case, empty strings) are not flagged.
  Additionally, removes the check for sandwiched null byte.
- Finally, adds the relevant update to struct and interface to
  reflect changes in Rust types.

…onfigured

What this commit does:
+ Updates the sanitization function for node alias to return NodeAlias
+ Updates the node alias type in the configuration to NodeAlias and implements a conversion to/from String for bindings
+ With this update, regardless of where the alias is set, i.e. in the set_node_alias or directly, sanitization occurs.

What this commit does:
+ Decomposes connect_open_channel into two different functions:
   open_channel and open_announced_channel. This allows opening
   announced channels based on configured node alias and listening
   addresses values.
+ This enforces channel announcement only on the condition that
    both configuration values are set.
+ Additionally, a new error variant `OpenAnnouncedChannelFailed`
    is introduced to capture failure.

    Note: I thought I added the `InvalidNodeAlias` variant in the
    previous commit

What this commit does:
+ Replaces calls to `connect_open_channel` with `open_channel` and
    `open_announced_channel` where appropriate.

Status: Work In Progress (WIP)

Observation:
+ The integration tests are now flaky and need further investigation
    to ascertain the reason(s) why and then to fix.

What this commit does:
+ Removes the wrapping Arc from the channel config. This is a missed
    update after rebasing.

This commit addresses changes necessary to:
- fix failing tests for generated bindings
- remove unnecessary error variant previously introduced to capture
  failure associated with opening announced channels, and re-use
  existing variants that better capture the reasons, i.e. `InvalidNodeAlias`
  and `InvalidSocketAddress`, why opening an announced channel failed.
- correct visibility specifiers for objects, and
- cleanup nitpicks

Specific modifications across several files include:
- updating the UDL file, as well as tests related to python and kotlin
  that call `open_channel` and/or open_announced_channel
- repositioning/rearranging methods and struct fields
- introducing enums (`ChannelAnnouncementStatus` & `ChannelAnnouncementBlocker`)
  to capture and codify channel announceable eligibility, providing reasons
  for unannounceable channels
- modifying `can_announce_channel` to utilize the aforementioned enums,
  as opposed to simply returning a boolean value.
- cleaning up and renaming `connect_open_channel` to `open_channel_inner`,
  and maintaining a boolean flag for channel announcement
- updating documentation, unit, and integration tests that factor all
  these changes

… addresses

This commit addresses flaky test issues related to conditional channel
opening between nodes, considering node aliases and listening addresses.

Changes in test modules:
- Add/modify helper functions to randomize channel announcement flags
- Generate random node aliases based on announcement flags:
  * Set custom alias if announce_channel is true
  * Use default alias otherwise
- Update channel opening logic to account for node and channel announcements

Set node alias

…ases and addresses"

This reverts commit 4fd1cb8 as unit
tests need to be kept deterministic, i.e., opening announced channels is
a deliberate choice on a per test case basis.

We improve the docs a bit, highlight the requirements for node aliases,
and that we'll only ever allow announcing channels if they are properly
set.

We drop the previously-introduced
`ChannelAnnouncementStatus`/`ChannelAnnouncementBlocker` types. While
informative, they were a bit too much boilerplate. Instead we opt to
simply return a `bool` from `may_announce_channel`, and don't spawn the
node announcment task to begin with if we're not configured properly.

Previously, we always opened announced channels in tests, but it should
be a deliberate choice depending on the scenario we're trying to test
for.

.. as we generally want to ~discourage users from arbitrarily opening
announced channels. They really only should do so if they are willing
and able to run a proper 24/7 forwarding node. And node operators will
likely know what to look for in the API.

We will be adding some wallet persistence/serialization related types
and in a separate module down the line, so here we perepare for it by
already moving the wallet code to a module directory.

... we update LDK, lightning-liquidity, BDK, rust-bitcoin, rust-esplora-client,
rust-electrum-client, etc.

…LDK-0.0.124-BDK-1.0

... which somehow was removed as part of the recent refactoring.

…in-place

Re-add `block_in_place` in `stop`

Since LDK v0.0.124 was yanked.

Upgrade LDK to v0.0.125

.. which will allow us to switch between different chain sources.