Invoice wrapping - Expose min_final_cltv_expiry_delta on receive_for_hash

[karliatto]

I wanted to implement a server that uses ldk-node for wrapping bolt11 invoice, the most straightforward use-case steps looks like:

1. A user wants to pay a BOLT11 invoice from a custodial wallet without the custodian learning who they are paying, so they use a service that wraps the invoice atomically.

2. The user gives the invoice to the proxy. The proxy issues a new invoice on the same payment hash for a slightly larger amount (routing budget + fee). The proxy does not know the preimage.

3. The user pays the wrapped invoice. The proxy holds that inbound HTLC without settling it, and pays the original invoice.

4. Paying the original invoice is how the proxy learns the preimage. Only then can it settle the HTLC it has been holding. It cannot get paid without paying first — this is what makes the swap atomic.

The risk is in step 3-4: while the proxy holds the inbound HTLC, that HTLC's cltv_expiry is the entire time budget for completing the outbound payment. If it expires first, the peer force-closes and claims on the timeout path — and if the outbound payment then succeeds, the proxy has paid out and can no longer claim in.

Sizing that budget requires setting min_final_cltv_expiry_delta on the wrapped invoice, which receive_for_hash does not expose, since receive_inner takes default one: https://github.com/lightningdevkit/ldk-node/blob/main/src/payment/bolt11.rs#L111

[benthecarman]

We are getting a combinatorial explosion of different thing things with amountless, external preimage, JIT channel, etc. Maybe making an Bolt11ReceiveBuilder or something would make this easier and we can easily expose functionality like this without having to complicate the API.