unified_qr: Consider continuing receive flow on offer creation failure

[tnull]

Currently, we error out UnifiedQrPayment::receive if we fail to create an offer. However, this could happen if we don't have suitable channels for blinded path creation. While it's not entirely clear what behavior is preferable, we should at least consider just continuing receive so that the user can always fall back to the onchain bip21 part.

[Anyitechs]

Hi @tnull, I'll like to work on this but I want to ensure I understand this correctly.

By continuing the receive flow, do you mean:

• Taking off the return statement from return Err(Error::OfferCreationFailed); and return Err(Error::InvoiceCreationFailed); on bolt12_offer and bolt11_invoice respectively and just propagate the error variant to the variable? Or,
• Not to worry about the offer and invoice creation failure (maybe only log the error but do not block the flow) and continue the receive flow?

Either way, do you think continuing the flow on offer/invoice creation failure won't affect the behaviour some wallets might expect from the BIP21 [URI] following this comment below on the UnifiedQrPayment::receive?

The URI allows users to send the payment request allowing the wallet to decide which payment method to use. This enables a fallback mechanism: older wallets can always pay using the provided on-chain address, while newer wallets will typically opt to use the provided BOLT11 invoice or BOLT12 offer.