qml: let user finalize forward swap onchain tx before initiating swap

[accumulator]

No description provided.

[f321x]

Tested, works fine for me. Maybe the minimal allowed tx fee should be limited in the tx finalizer to an ETA limit < LOCKTIME_DELTA_REFUND (+ buffer), otherwise it seems easy to lose money by cheaping out on the tx fees.
E.g. the user selects 1 sat/vb for a non urgent swap in the hope it will confirm in the next weeks (or months) during a large mempool, not knowing there are time limitations to swaps. Then he will have to broadcast a refund tx later and waste fees for nothing (ignoring the case of not opening the wallet at all, as we show a warning for this).

Also noticed these two qml logs while testing:
After confirming the swap, while receiving the htlcs:
331.59 | W | gui.qml.qeapp | file:///home/user/code/electrum-fork/electrum/gui/qml/components/Channels.qml:124:13: QML FlatButton: Binding loop detected for property "enabled"

When clicking on the input/output dropdown in the tx finalization dialog:
147.06 | W | gui.qml.qeapp | Qt Quick Layouts: Detected recursive rearrange. Aborting after two iterations.
This seems to be an issue with the this dialog, also happens when i do a regular onchain tx.

I can also open separate issues if they are out of scope of this PR.

[accumulator]

Tested, works fine for me. Maybe the minimal allowed tx fee should be limited in the tx finalizer to an ETA limit < LOCKTIME_DELTA_REFUND (+ buffer), otherwise it seems easy to lose money by cheaping out on the tx fees. E.g. the user selects 1 sat/vb for a non urgent swap in the hope it will confirm in the next weeks (or months) during a large mempool, not knowing there are time limitations to swaps. Then he will have to broadcast a refund tx later and waste fees for nothing (ignoring the case of not opening the wallet at all, as we show a warning for this).

Yes, good idea. I'm leaning towards disabling static fees in these cases, only allowing finalizing when dynamic fees (ETA, mempool) are available. What do you think @f321x?

Also noticed these two qml logs while testing: After confirming the swap, while receiving the htlcs: 331.59 | W | gui.qml.qeapp | file:///home/user/code/electrum-fork/electrum/gui/qml/components/Channels.qml:124:13: QML FlatButton: Binding loop detected for property "enabled"

When clicking on the input/output dropdown in the tx finalization dialog: 147.06 | W | gui.qml.qeapp | Qt Quick Layouts: Detected recursive rearrange. Aborting after two iterations. This seems to be an issue with the this dialog, also happens when i do a regular onchain tx.

I can also open separate issues if they are out of scope of this PR.

There are a few places where these frontend issues are still logged. For the binding loops I don't really see how they are getting triggered. They seem to be harmless. The layout issues are sometimes logged when anchoring an Item outside a layout to items within a Layout. Also seems mostly harmless.

[f321x]

@accumulator i think only allowing ETA and capping the max allowed ETA would be the safest way. Static rates and mempool seem easy to get wrong for the funding tx. It seems nice to have the flexibility to save some fees for non-urgent swaps but the risk of a failing (refunded) swap by setting too low fees should be minimal imo.