Split lightning address settings into global and pubkey specific

[myxmaster]

Description

(#2687 needs to be merged first.)

Right now we have all lightning address settings as global settings, but enabled and nostrPrivateKey need to be pubkey-specific (not node specific, that is the tricky part). Since we can only obtain the pubkey after we are connected to the node, the migration for this (migrateLightningAddressSettings()) is called after getNodeInfo() in Wallet.tsx (not like other migrations which are called in getSettings()).

Before, LightningAddressStore:status(); was often times not called at all in Wallet.tsx:fetchData(), because the flag enabled (for LightningAddress) was false globally (and never corrected). Now it will be correct (or corrected automatically) for all nodes (pubkeys).

To make sure there won't be any conflicts/mixed data, it is ensured the migration only runs after other migration methods are finished.

Additionally:

• removed require cycle warning in MigrationUtils by using storeInstances
• added logic to ensure we skip calling migration methods (legacySettingsMigrations and storageMigrationV2) again if already running (getSettings() is called 2x in quick sequence)
• removed unused LEGACY_ADDRESS_ACTIVATED_STRING and ADDRESS_ACTIVATED_STRING and unused method getLightningAddressActivated() in LightningAddressStore.ts.
• added uuid to package.json to ensure it is explicitly declared (even though it is currently available through other deps)

This also fixes #2730.

This pull request is categorized as a:

• New feature
• Bug fix
• Code refactor
• Configuration change
• Locales update
• Quality assurance
• Other

Checklist

• I’ve run yarn run tsc and made sure my code compiles correctly
• I’ve run yarn run lint and made sure my code didn’t contain any problematic patterns
• I’ve run yarn run prettier and made sure my code is formatted correctly
• I’ve run yarn run test and made sure all of the tests pass

Testing

If you modified or added a utility file, did you add new unit tests?

• No, I’m a fool
• Yes
• N/A

I have tested this PR on the following platforms (please specify OS version and phone model/VM):

• Android
• iOS

I have tested this PR with the following types of nodes (please specify node version and API version where appropriate):

• Embedded LND
• LND (REST)
• LND (Lightning Node Connect)
• Core Lightning (CLNRest)
• LndHub
• [DEPRECATED] Core Lightning (c-lightning-REST)
• [DEPRECATED] Core Lightning (Spark)
• [DEPRECATED] Eclair

Locales

• I’ve added new locale text that requires translations
• I’m aware that new translations should be made on the ZEUS Transfix page and not directly to this repo

Third Party Dependencies and Packages

• Contributors will need to run yarn after this PR is merged in
• 3rd party dependencies have been modified:
  • verify that package.json and yarn.lock have been properly updated
  • verify that dependencies are installed for both iOS and Android platforms

Other:

• Changes were made that require an update to the README
• Changes were made that require an update to onboarding

[myxmaster]

I wonder if status() is really needed here, it is a lot slower than the new checkLightningAddressExists().

Either way, this can be optimized since status() and checkLightningAddressExists() have overlapping functionality (both ask zeuspay backend for LN address).

[myxmaster]

I did this because migration method migrateLightningAddressSettings() also calls this and it will hang if backend doesn't answer. 10s should be more than enough imo...

[kaloudis]

mm there's gotta be a better way to handle that

[myxmaster]

Well, if we want correct data after migration, we have to look up if ln address exists for current pubkey. Since before enabled was a global setting, we cant rely on that.

Or do you mean how to achieve the timeout?

[kaloudis]

What if we run this one in series after the other migrations?

[myxmaster]

That is not possible because at that point (during getSettings()) we don't have the node pubkey yet. That's why I call migrateLightningAddressSettings() in fetchData() right after await NodeInfoStore.getNodeInfo();.

[myxmaster]

It is not so bad really, checkLightningAddressExists() only runs once per node. Not even that actually, it is skipped if that pubkey was checked already. And chances are low that backend is not responding too...

[kaloudis]

thinking about this now, we may want to pair these with each address, otherwise it is really easy to get out of sync.

Alternatively, we don't store it at all and and modify the service to return these

[myxmaster]

Yeah, before this PR, it is often out of sync, because it is a globl setting.

I didn't think about pulling it from backend too. Not a bad idea! Let me know, then I'll add that.

[myxmaster]

rebased/solved conflicts