Expose updated swap fees for user review

[danielgranhao]

Resolves #602

With this PR:

• Users can provide an onchain fee rate leeway in sat/vbyte that they are fine with
• When auto-accepting isn't possible, the payment gets into the new WaitingFeeAcceptance state. It will stay there until the user accepts the new fee, refunds the swap, or the swap expires
• Listing payments waiting for review is done using the existing method list_payments
• users can accept the new fees, proceeding with the payment. Otherwise, they can immediately refund the swap.

[roeierez]

I Very like the concept! Added some comments.

[roeierez]

Looks good to me, only brainstorming naming conventions.

[danielgranhao]

This will need to be rebased on top of #620 in order for payments WaitingFeeAcceptance to be shown in the payments list. The core logic proposed here can already be reviewed though.

Also, I propose we update the notification plugins in a separate PR.

[roeierez]

@danielgranhao I did an initial pass and it looks solid to me, both the interface and the implementation. I still need to dig more into the code.
I think we need also to add a sync trigger when the payer_amount/receiver_amount changes now that we have the realtime sync in place.

[danielgranhao]

@roeierez Thanks! In the meantime, I've also identified some minor issues that need fixing. Once it's ready, I'll mark it.

[dangeross]

I think we should be able to recover the WaitingFeeAcceptance state, if there is only a user lockup tx and the swap payer/receive amount is 0

[danielgranhao]

I think we should be able to recover the WaitingFeeAcceptance state, if there is only a user lockup tx and the swap payer/receive amount is 0

@dangeross Hm.. I don't think so. Those conditions would still apply even after the user accepts the fees, after which the state should be Pending. IIUC, the WaitingFeeAcceptance state requires info from the swapper service, and cannot be determined from onchain data and local state alone. But I could be missing something

[roeierez]

I think we should be able to recover the WaitingFeeAcceptance state, if there is only a user lockup tx and the swap payer/receive amount is 0

@dangeross we had a discussion previously this week and decided to only transition to WaitingFeeAcceptance at the initiator end (local swap). This way the call to action will only be decided there and the rest of the synced devices will see the payment as pending. This is mainly for simplicity. Do you see any issue with that?

[dangeross]

Those conditions would still apply even after the user accepts the fees, after which the state should be Pending

If there is no server lockup tx, a user lockup tx and 0 amount it could be determined to be WaitingFeeAcceptance. Once accepted the payer/receiver amounts are updated and we should see a server lockup tx, then we could move on to Pending

[dangeross]

Do you see any issue with that?

I can't think of an issue

[danielgranhao]

If there is no server lockup tx, a user lockup tx and 0 amount it could be determined to be WaitingFeeAcceptance

The issue is we want to update the amount before moving to WaitingFeeAcceptance so that we can show the user the value of the payment waiting for fee acceptance. We would have to persist some additional data, like the fact that fees have been accepted, in order to distinguish between both states. Maybe that's the way forward?

[dangeross]

LGTM