General refactoring mainly regarding MobX actions + fixed error state

[myxmaster]

Description

• Add missing public/private decorators
• Convert public methods to private where appropriate
• Remove unused methods
• Add @action decorator where appropriate
• Use runInAction in async methods
• Fix loading states in BalanceStore methods (set state after reset)
• Refactored channel backup methods (untested)
• Set error state in error handlers

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 did a lot of testing, couldn't find any issues.

[kaloudis]

I'm quite confused by a lot of the use of the runInAction pattern. In many of the cases in this PR, the @action decorator is removed in favor of the wrapped function. This seems unnecessary to me.

[kaloudis]

Also, if we're going to use runInAction at all, we should configure mobx to run in strict mode https://github.com/mobxjs/mobx/blob/mobx4and5/docs/refguide/api.md#enforceactions

I'm not convinced this has a bunch of benefits though. Curious to hear more about your motivations here.

[myxmaster]

The @action decorator does not work with asynchronous code.

Let's look at the following function:

@action
public load = async () => {
    this.loadingBlockchainBalance = true;
    this.loadingLightningBalance = true;
    await this.load();
    this.loadingBlockchainBalance = false;
    this.loadingLightningBalance = false;
};

One could assume this results in two render function calls. But in fact it's three. The @action decorator works for state changes before the await but it doesn't have any effect on the state changes after it. Changing the function to this results in only two renders:

@action
public load = async () => {
    this.loadingBlockchainBalance = true;
    this.loadingLightningBalance = true;
    await this.load();
    runInAction(() => {
        this.loadingBlockchainBalance = false;
        this.loadingLightningBalance = false;
    });
};

I verified that with console outputs in the render function.

Enabling strict mode would force us to use @action or runInAction even if a function only changes one state property which would have no benefit. But of course without strict mode one has to remember adding @action decorator or wrapping the code in runInAction if another property change is added.

[myxmaster]

rebased/solved conflict

[myxmaster]

rebased/solved conflict