Liquid/Lightning drain

[dangeross]

This PR:

• fixes drain tx (drain tx fee estimate) to use the lowball fee
• estimate fees for liquid/mrh/lightning with fallback to drain fees
• attempt to fallback to drain txs for paying to liquid or send swap lockup
• blocks draining while there are pending payments

It's difficult to add a drain option to the PrepareLnUrlPayRequest because at the point when preparing we don't know if the LNURL invoice response will contain an MRH or not for a direct Liquid tx. Because of this we can't calculate an invoice amount to drain for both options. See #559

TODO

• Add drain option to to prepare_send_payment 80830de

Fixes #543
Fixes #550

[ok300]

Looks good!

[roeierez]

It's difficult to add a drain option to the PrepareLnUrlPayRequest because at the point when preparing we don't know if the LNURL invoice response will contain an MRH or not for a direct Liquid tx. Because of this we can't calculate an invoice amount to drain for both options.

Do you think it is reasonable to calculate for one case (let's say without routing hints) and if we get one with routing hints fetch again?

[roeierez]

The name is a bit confusing because we use onchain for bitcoin.
do you think it makes sense to use amount_sat as before and add the drain option default to false?

[dangeross]

I feel like the drain option should be an explicit opt-in and would be more consistent with the drain to Bitcoin. I would rather rename the PayOnchainAmount to something like DrainableAmount. Happy to revert to use the amount_sat if you prefer.

[roeierez]

Perhaps rename to SendPaymentAmount or PayAmount ?

[dangeross]

Do you think it is reasonable to calculate for one case (let's say without routing hints) and if we get one with routing hints fetch again?

I think it's a reasonable solution. I thought about just sending the drain amount to the MRH of the first invoice also, but this way seems cleaner