Send & Chain: Localize refund flow to swap handlers

[hydra-yse]

This PR aims at fixing the refund flow loop, since it used to block the status stream thread while waiting for lockups to be confirmed. The logic has been moved to the swap handlers, so they are now independent from the swapper (currently only used for broadcasting). The logic for constructing the refund tx (only Liquid) has also been moved to the SDK side due to problems with lowball, and the requirement to fetch from our Esplora.

The current improvements make cooperative refunds happen almost instantaneously, and with no reliance on the swapper. In case of no Boltz status update, they will be refunded non-cooperatively on locktime expiry (via LiquidSdk::track_pending_swaps).

[dangeross]

I think by not explicitly checking the swap expiration and first relying on the swap state you are assuming Boltz is always being compliant (or functional). If swap a state is not changed to RefundPending (for outgoing chain/send swaps) in the stream updates, then there is never an attempt to refund

[roeierez]

@hydra-yse IMO the coopertive refund which should in theory always succeed should be executed immeditely as soon as we understand we need it so having it as part of the status stream as before makes sense to me.
I do agree that making the non cooperative refund only in one place (the watcher task) is a good idea since anyway we will execute it only on exiration and we are not relying on boltz statuses for that but only on chain information.

[roeierez]

The code as is is not clear and hard to understand (not because of this PR) so I certainly understand the motivation to do some cleanup here.
IMO a clean approach would be:

1. Create a new module (file) refund.rs
2. In there we will have two structures (SendSwapRefunder, ChainSwapRefunder)
3. Each of them has two functions:

• Refund(swaps: []swap) - will attempt first cooperatively and if fail and timeout is applicable will try non cooperatively.
• RefundExpired() - which will query the db for those that are refundables and use the former method to refund.

Now our two cases can use the above functinoality:

1. From the status stream when need to refund just call Refund (swaps).
2. From a background thread that runs periodically and only calls RefundExpired().

What do you think @hydra-yse ?

[hydra-yse]

There are still some checks/tests to do, so I will be leaving it as draft for now, though I would appreciate a review on the interface changes 😄 . @roeierez I'll clarify later today why I think creating a separate refund.rs sounds good but has some practical issues, and why I decided to opt for this approach instead.
Note: I've still taken inspiration for the refund and refund_expired methods you suggested, as they made the whole call structure easier to read.

[hydra-yse]

@dangeross I've also addressed Pending swap tracking in 9113ce1, so that even if Boltz doesn't return the right state we can still try non-cooperatively after the expiry. Just have to propagate the changes to chain swaps.

[roeierez]

It looks a lot better IMO. I also like the fact that every module (chainswap, send_swap) takes care of its own refunds.
I still need to do another pass.

[hydra-yse]

A note about 2d65bbb: I think waiting 10 minutes is a reasonable tradeoff which ends up saving us both bandwidth and computation time. Since the current method attempts a non-cooperative refund even when the swap is Pending (therefore even for swaps which may become successful soon) I think it's not worth trying to refund straight away but rather just wait some time for the swap to complete.

[hydra-yse]

Just a comment for @dangeross, I've reverted the script history check here to avoid re-fetching. It occurs anyway when reconstructing the refund transaction (utils::new_lbtc_refund_tx) so there shouldn't be any problems there.

[roeierez]

@hydra-yse is this ready for another review? If so can you please rebase the conflicts?

[roeierez]

Looks good!

[roeierez]

LGTM