[v0.9.0] Custom route hints

[myxmaster]

Description

This pull request introduces optional 'custom route hints'. With custom route hints users can now decide which lightning channels are put into an invoice as additional information for the sender to be able to use those channels for the payment. In practice this enables users to top up specific channels by receiving sats via any lightning payment or by using external swap services.

Additionally:

• Fixed a bug for the hop picker in PaymentRequest. Clearing a hop did not work and the hop was still used.
• Renamed the confirm button in hop picker modal dialog from 'Set channel' to 'Confirm' to mitigate singular/plural problem.
• Made confirm button disabled when no channel is selected.

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 (c-lightning-REST)
• LndHub
• [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

[kaloudis]

Looks great so far. Might have some conflicts once External accounts goes in. We'll cut out a feature branch for v0.9.0 to go into while we're still rolling out v0.8.4

Just lmk if you'd like an LNC instance to test against.

[myxmaster]

Forgot to update backends/LightingNodeConnect.ts in original PR, so that is done now.

Tested it, but I'm a bit confused because with LNC backend the chan id in the actual route hint of the invoice differs (just a little bit for the last digits) to the chan id of the channel that was selected (e.g. 276BDF0000250000 vs. 276bdf0000250018). Not sure if that is a problem, waiting for tests from @kaloudis.

[myxmaster]

After investigating this I found out that this is no LNC specific problem (it was just luck that it didn't happen with LND). The problem was the conversion of the channel id to Number which sometimes leads to a loss of precision since the number is too big for javascript Number. Fortunately the backend also accepts it as string.

Also resolved the conflicts.

[myxmaster]

Tested with embedded LND. It generally works but there is an already existing problem with the channel ids. The backend (sometimes?) provides invalid ids so that retrieving channel infos sometimes does not work (edge not found). The cause is probably a conversion to Number which leads to a loss of precision. Example: Channel id from our node to Olympus testnet node: 3090127951852011500 (hex: 2AE257 0000A4 FFEC). FFEC is the tx output index which is wrong (channel point: 5587b84bf0fd43125eb3faea5f786c5c5e84bc06b4711e0b0fff906740fab1a5:0 -> output index is 0).

This can be merged, the channel id problem should be fixed separately.

[kaloudis]

Tested with embedded LND. It generally works but there is an already existing problem with the channel ids. The backend (sometimes?) provides invalid ids so that retrieving channel infos sometimes does not work (edge not found). The cause is probably a conversion to Number which leads to a loss of precision. Example: Channel id from our node to Olympus testnet node: 3090127951852011500 (hex: 2AE257 0000A4 FFEC). FFEC is the tx output index which is wrong (channel point: 5587b84bf0fd43125eb3faea5f786c5c5e84bc06b4711e0b0fff906740fab1a5:0 -> output index is 0).

This can be merged, the channel id problem should be fixed separately.

Have you checked the raw responses from the endpoints? I'm curious if it's an issue with the REST API or our conversion somewhere.

[myxmaster]

No, not yet. But again, I think it's really something for another PR.

[kaloudis]

LGTM