feat(lightning): using on chain address for channel close

[Jasonvdb]

Description

• Updates react-native-ldk to include a change where funds from a channel close are sent direct to Bitkit's on chain wallet and no longer require and extra sweeping step.
• Also includes a fix preventing some users from completing the restore flow

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactoring (improving code without creating new functionality)

Tests

• Detox test
• Unit test
• No test

QA Notes

• Funds should show up directly on chain after channel close
• Some users stuck on restoring screen should not be able to progress

[pwltr]

Can you fix the failing onboarding e2e test?

needs UI work

[pwltr]

Actually although this works I think we'd want more work on the UI to avoid confusing the user. Right now it shows a pending card (60m) but at the same time also shows an activity item (10-20m) not marked as transfer.

[pwltr]

Will approve because UI was not in the scope

[coreyphillips]

Instead of using generateNewReceiveAddress we'll want to grab what the current addressIndex is instead. Since generateNewReceiveAddress will always create a new address regardless of whether or not the previous index was used. This means opening and closing the app a few times will end up pushing the user's addressIndex into the gap limit. I'll make a change suggestion for this shortly.

[Jasonvdb]

Can you fix the failing onboarding e2e test?

I was seeing webRelayClient not ready yet in all the PR's? Unless you mean another test?

[Jasonvdb]

Instead of using generateNewReceiveAddress we'll want to grab what the current addressIndex is instead. Since generateNewReceiveAddress will always create a new address regardless of whether or not the previous index was used. This means opening and closing the app a few times will end up pushing the user's addressIndex into the gap limit. I'll make a change suggestion for this shortly.

Oh yes right. So originally I had it use getReceiveAddress and I changed it to return IAddress instead of a string but I thought maybe I was breaking something with the store and didn't want to go down that path right before testing session.

[pwltr]

Can you fix the failing onboarding e2e test?

I was seeing webRelayClient not ready yet in all the PR's? Unless you mean another test?

Was talking about this:

FAIL e2e/onboarding.e2e.js (109.532 s)
  Onboarding
    ✕ Can pass onboarding correctly (101505 ms)

  ● Onboarding › Can pass onboarding correctly

    expect(received).toBe(expected) // Object.is equality

    Expected: "bitcoin:bcrt1q2zkt93dtl8cxqgtvzxurlu0mu6z6ahnh6sy5uf"
    Received: "bitcoin:bcrt1qjz82ap0k2x6r7zg9jketlthx8whm0dne8f0cvx"

      120 | 		const { label: address2 } = await element(by.id('QRCode')).getAttributes();
      121 |
    > 122 | 		jestExpect(address1).toBe(address2);
          | 		                     ^
      123 |
      124 | 		markComplete('onboarding-1');
      125 | 	});

Will be fixed by what @coreyphillips described above 👍

[coreyphillips]

Oh yes right. So originally I had it use getReceiveAddress and I changed it to return IAddress instead of a string but I thought maybe I was breaking something with the store and didn't want to go down that path right before testing session.

PR created here. Since most of this will be changed once the beignet migration is merged anyway I simply created a new method that is effectively the same as getReceiveAddress except it returns the entire object. Will make it easier to merge the changes in later on.