One chain source to rule them all

[dangeross]

This PR:

• tracks new blocks and trigger swap checks/rescans for that block
• recovers and stores onchain data for every monitored swap
• partially syncs to pickup direct Liquid or MRH txs in the mempool
• triggers PaymentWaitingConfirmation event for receive payments via MRH tx when in the mempool
• prevents duplicate SDK events by comparing swap before/after update

TODO (in a followup PR):

• Reuse fetch of chain data from the swap update ws loop
• Trigger any claims/refunds based on fetched chain data

Every new liquid block:
- Fetch onchain data for all swaps that are not in final state (not in succeed, refunded) we can skip expired more than X blocks behind like we do today for efficiency.
- For refundable send lightning swaps refund if needed.
- For claimable receive lightning swaps, claim if needed. (zero conf claims can still be handled from the web socket loop).
Every new bitcoin block:
- fetch onchain data forFetch onchain data for All onchain swaps (both send/receive) -  we can skip expired more than X blocks behind like we do today for efficiency.
- For refundable send onchain swaps refund if needed.
- For claimable receive onchain swaps claim if needed.
Notes:
- In order to get a new block event we can query electrum every 10 seconds for the current tip (shouldn’t be too expensive).
- For both liquid and bitcoin we start by fetching the onchain data aggregated for all swaps we need, persisting it and then acting on refundables or claimables.
I think this should cover the following cases (let’s verify):
- Non functioning swapper web socket statuses
- Records coming from realtime sync (created and controlled on another device).
- Failure to claim/refund from the swapper websocket status loop.

[roeierez]

Do we list here also received swaps that were expired?

[dangeross]

No, but the expiry will be the same as the invoice expiry, so the invoice shouldn't be valid. At this point also the MRH address can be reused from the address pool, so shouldn't be associated to the swap

[roeierez]

Will this send trigger a payment event? Previously the event was triggered only on change.

[dangeross]

I think they are repeated anyway in some cases. I seem to remember seeing multiple PaymentPending or PaymentWaitingConfirmation events. Probably because its valid to update Pending to Pending even if the details are the same.

[roeierez]

I mean also on the update_swap_info occurences bellow we don't seem to be checking if it is a really state transition so it looks like on every sync we will get payment events.
Previousely the code was checking for every associated claim if it really transitioned to from mempool to confirmed (completed) or just intruduced as undonfirmed (pending) before emitting events.

[roeierez]

Looks good!