Feature: allow generating invoice_requests without an offer

[AndySchroder]

At

https://github.com/rustyrussell/lightning-rfc/blob/db73bbb64d2dfc07fbc9c1dc09259d827f703868/12-offer-encoding.md?plain=1#L367

we have

The second case is publishing an `invoice_request` without an offer,
such as via QR code.  It contains neither `offer_issuer_id` nor `offer_paths`, setting the
`invreq_payer_id` (and possibly `invreq_paths`) instead, as it in the one paying: the
other offer fields are filled by the creator of the `invoice_request`,
forming a kind of offer-to-send-money.

and I'd like to have this capability.

It would make sense to be able to be able to automatically wait for the invoice to be received and then show the invoice. In addition, it would also be nice to be able to wait for the invoice to be received and then automatically pay it if the invoice amount matches the invoice_request amount.

[AndySchroder]

More context: https://github.com/rustyrussell/lightning-rfc/blob/db73bbb64d2dfc07fbc9c1dc09259d827f703868/12-offer-encoding.md?plain=1#L54

The merchant-pays-user flow (e.g. ATM or refund):
1. The merchant publishes an *invoice_request* which contains offer fields
   which refer to its attempt to send money, including an amount.
2. The user sends an *invoice* over the lightning network for the amount in the
   *invoice_request*, using a (possibly temporary) *invoice_node_id*.
3. The merchant confirms the *invoice_node_id* to ensure it's about to pay the correct
   person, and makes a payment to the invoice.

[orbitalturtle]

Agree, we should definitely add support for refunds at some point. Leaving this link here in case anyone is able to look into this: https://docs.rs/lightning/latest/lightning/offers/refund/struct.Refund.html

[AndySchroder]

Related: https://lightningdevkit.org/blog/bolt12-has-arrived/#achieving-statelessness .

[AndySchroder]

With https://github.com/lndk-org/lndk/issues/181, we should be able to receive the invoice back over a local physical link so that it can be paid with the existing pay-invoice. There would need to be some way to validate the invoice received is indeed in response to the invoice_request before using pay-invoice though.