feat: implement remote feature flag controller

[joaoloureirop]

Description

Introduction of @metamask/remote-feature-flag-controller library.

Remote feature flag controller manages data flow, retry policy, and cache expiry.
The controller consumer manages default values, data persistency, and data distribution.

See ADR for a in-depth description

Technical decisions

Controller init on Engine.ts with feature flags fetching only on cold app starts.

@metamask/remote-feature-flag-controller is only asked to fetch feature flags after its init in Engine.ts. Ensures feature flags are only fetched on cold app starts.

Fallback values

Default values are used when remote feature flags are undefined.
The fallback mechanism is implemented by each feature flag selector app/selectors/featureFlagsController/<featureFlagName>

In this PR we include minimumAppVersion selector, which manages the LD feature flag mobile-minimum-versions

One selector per each feature flag

LD feature flags can be boolean, number, strings on JSON objects.
We've decided to have each feature flag with its own selector

A feature flag selector contains:

• state selectors for each feature flag value.
• business logic
• defaults for when feature flags values are undefined.
• TS types.
• unit tests and mocked data.

This architecture offers a clear separation between each feature flag and the logic behind it, allowing easier manipulation.
Code owners are assigned to each feature flag.

Related issues

Fixes: https://github.com/MetaMask/mobile-planning/issues/2054
Fixes: https://github.com/MetaMask/mobile-planning/issues/1975

Manual testing steps

1. Go to this page...

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I’ve followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[github-actions]

Bitrise

✅✅✅ pr_smoke_e2e_pipeline passed on Bitrise! ✅✅✅

Commit hash: 9cd1bf0
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/18207d2d-9854-41b3-916d-d079e3ca8ba8

Note

• You can kick off another pr_smoke_e2e_pipeline on Bitrise by removing and re-applying the Run Smoke E2E label on the pull request

[NicolasMassart]

update tests please

[joaoloureirop]

I've revisited the controller initialisation testing.

• unit test that can't be validated without mocking the feature flag service were removed.
• unit tests names were improved.

For the selector, the unit test names were updated

Thanks for your review @NicolasMassart

[NicolasMassart]

allowing myself to fix some typos and missing 'when' directly

[github-actions]

Bitrise

❌❌❌ pr_smoke_e2e_pipeline failed on Bitrise! ❌❌❌

Commit hash: 7d59ace
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/c37fffe4-8bd7-4b96-9ebd-bb90f5d49aac

Note

• You can kick off another pr_smoke_e2e_pipeline on Bitrise by removing and re-applying the Run Smoke E2E label on the pull request

Tip

• Check the documentation if you have any doubts on how to understand the failure on bitrise

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
84.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[NicolasMassart]

Looks good to me on the code side.