Add test for dummy hop insertion

Introduces a test to verify correct handling of dummy hops
in constructed blinded paths.
Ensures that the added dummy hops are properly included and
do not interfere with the real path.

Co-authored-by: valentinewallace <valentinewallace@users.noreply.github.com>

Introduce flow & usage in ChannelManager

Introduce flow & usage in ChannelManager

Introduce flow & usage in ChannelManager

Introduce flow & usage in ChannelManager

Add test for dummy hop insertion

Introduces a test to verify correct handling of dummy hops
in constructed blinded paths.
Ensures that the added dummy hops are properly included and
do not interfere with the real path.

Co-authored-by: valentinewallace <valentinewallace@users.noreply.github.com>

Add test for dummy hop insertion

Introduces a test to verify correct handling of dummy hops
in constructed blinded paths.
Ensures that the added dummy hops are properly included and
do not interfere with the real path.

Co-authored-by: valentinewallace <valentinewallace@users.noreply.github.com>

Expand Test suite

- Expand testing to ensure proper serialise-deserialise round-trip for
all events.
- Expand a multi-Part payment test to ensure that all the channel ids &
  user channel ids are present in the PaymentClaimable event

v0.1.3 - Apr 30, 2025 - "Routing Unicode in 2025"

Bug Fixes
=========

 * `Event::InvoiceReceived` is now only generated once for each `Bolt12Invoice`
   received matching a pending outbound payment. Previously it would be provided
   each time we received an invoice, which may happen many times if the sender
   sends redundant messages to improve success rates (lightningdevkit#3658).
 * LDK's router now more fully saturates paths which are subject to HTLC
   maximum restrictions after the first hop. In some rare cases this can result
   in finding paths when it would previously spuriously decide it cannot find
   enough diverse paths (lightningdevkit#3707, lightningdevkit#3755).

Security
========

0.1.3 fixes a denial-of-service vulnerability which cause a crash of an
LDK-based node if an attacker has access to a valid `Bolt12Offer` which the
LDK-based node created.
 * A malicious payer which requests a BOLT 12 Invoice from an LDK-based node
   (via the `Bolt12InvoiceRequest` message) can cause the panic of the
   LDK-based node due to the way `String::truncate` handles UTF-8 codepoints.
   The codepath can only be reached once the received `Botlt12InvoiceRequest`
   has been authenticated to be based on a valid `Bolt12Offer` which the same
   LDK-based node issued (lightningdevkit#3747, lightningdevkit#3750).

Expand Test suite

- Expand testing to ensure proper serialise-deserialise round-trip for
all events.
- Expand a multi-Part payment test to ensure that all the channel ids &
  user channel ids are present in the PaymentClaimable event