feat(connext): unlock expired transfer apps

[ghost]

This PR adds logic to attempt to unlock expired connext transfer apps when receiving EXPIRED response from /hashlock-status.

Closes #1849

[raladev]

1. it would be good to have simtest for this case (if we can control expiry blocks number on the connext side)
2. or at least integration test (mocking hashlock response with/without EXPIRED field)
3. Also, @erkarl may u check tests status? it seems they are in infinite loop. I restarted them once and got same result.

[sangaman]

I'm a bit confused as to what this is doing (some comments might be good). Why are we "settling" a payment where we are the sender? I know that "invoice" is not exactly a connext term/concept, maybe we should just use the connext call/terminology directly here rather than settleInvoice which is a generic SwapClient method.

[ghost]

When the connext transfer (HTLC) expires the funds are not automatically returned to the channel balance. Expired transfer apps can be unlocked by both the receiver and sender by calling /hashlock-resolve with the paymentId.

In this PR the settleInvoice function has been modified to always include the paymentId in the body of the request in case the transfer has been expired.

It's worth noting that the node also periodically cleans up the expired transfer apps, but from UX perspective it's better if this happens from xud side. This ensures that the funds locked in the transfer app are available to the user sooner.

I've added a short comment above the settleInvoice call.

maybe we should just use the connext call/terminology directly here rather than settleInvoice which is a generic SwapClient method

Are you suggesting to create a wrapper function here that internally calls settleInvoice?

[sangaman]

OK, thanks for the explanation this makes sense. I think it would be great to put a brief summary of this in a line or two of comments right above this call.

I think calling settleInvoice here with a blank preimage is still a bit odd, I would just go ahead and call /hashlock-resolve directly like so:

await this.sendRequest('/hashlock-resolve', 'POST', {
  assetId,
  paymentId: sha256(['address', 'bytes32'], [assetId, `0x${rHash}`]),
});

And the settleInvoice call can be left as it currently is unless you think the payment id is useful to include even when we have the preimage?

[ghost]

Updated.

And the settleInvoice call can be left as it currently is unless you think the payment id is useful to include even when we have the preimage?

Yep, removed payment id from settleInvoice.

[ghost]

2. or at least integration test (mocking hashlock response with/without EXPIRED field)

Integration test already exists in this PR.

3. Also, @erkarl  may u check tests status? it seems they are in infinite loop. I  restarted them once and got same result.

Tests should now pass.

[ghost]

EDIT: removed. Wrong issue.

[sangaman]

Looks great, thank you.