feat: add util to fetch global and chain feature flags at once

[infiniteflower]

This PR implements the changes found in branch patch/mobile-swaps-v6.9.3-stx, which was a patch for Mobile

It does the following:

1. Adds fetchSwapsFeatureFlags as a util function which allows Mobile to fetch global and chainId specific feature flags all at once.
2. Adds relevant tests

[nikoferro]

@infiniteflower just to double check, this does not rely in any way on previous patches, is that correct?

asking this since we are removing current ones on MetaMask/metamask-mobile#9286

[legobeat]

I suggest making these snake_case for consistency and the changing all of them (including the _active flags above) to camelCase in a follow-up PR.
That way:

• This PR can be kept non-breaking and scoped
• Consistency is kept
• No need for duplicate flags (fallback_to_v1 plus fallBackToV1)
• Eventually this will conform to the global style and use camelCase

[infiniteflower]

I was just dumping all of the raw feature flags from the endpoint directly so that's why there's all these sort of overlapping values.

[legobeat]

Ah. So maybe it makes sense to make two types: One to interface with that API (using something like here) and one used internally and everywhere else (using a consistent, internal API). The consumption of the API would then involve parsing one to the other. Does that make sense?

[infiniteflower]

Yea makes sense, I'll adjust the types so there's no breaking changes.

To provide some context around this function, I just wanted to give clients the ability to consume the raw API directly, otherwise it necessitates we would have to update to the SwapsController if things fall outside of the current utils function such as in the STX case where the STX feature flags are outside of any chain specific feature flags.

So to just give the clients more flexibility, this util function just gives the raw endpoint result back to the client.

[infiniteflower]

Actually I suggest refactoring the API in another PR as it would mean we need to refactor the clients as well. I just need fetchSwapsFeatureFlags to accommodate Smart Transactions.

My type updates are simply reflecting the current state of the SwapsController return values. Without the change to:

export type NetworkFeatureFlags = {
  mobile_active: boolean;
  extension_active: boolean;
  fallback_to_v1?: boolean;
  fallbackToV1: boolean;
  mobileActive: boolean;
  extensionActive: boolean;
  mobileActiveIOS: boolean;
  mobileActiveAndroid: boolean;

  smartTransactions: {
    expectedDeadline: number;
    maxDeadline: number;
    returnTxHashAsap: boolean;
  };
};

The return values from fetchSwapsFeatureLiveness are not properly typed.

[legobeat]

The idea here would be precisely to make the clients-facing API more stable. So in this first step, we can just stick to the existing interface, extended with flags necessary for the purpose of the functionality in this PR.

Then the types used to interface with the server API would be what you write here.

And any translation necessary (e.g. case-insensivity, supporting two different spellings of the same value, or response validation/error handling) could be handled in fetchSwapsFeatureLiveness.

This way:

• No breaking changes needed
• Future changes in controller<>client API does not need to involve server
• Future changes in server<>controller API does not need to involve client
• The API presented from this controller can do better despite "The return values from fetchSwapsFeatureLiveness are not properly typed."
• There is a clear path towards cleaning it up further down the line

[legobeat]

If more flexibility and decoupling is desired for use of the data that is actually unrelated to the swaps controller itself, maybe the currently static feature flags could be made into optional runtime configuration, with the existing ones as default?

[infiniteflower]

Done, I've reverted the interface for NetworkFeatureFlags and NetworksFeatureStatus for fetchSwapsFeatureLiveness back to their original states.

I've added NetworkFeatureFlagsAll and NetworksFeatureStatusAll for use with fetchSwapsFeatureFlags, which would basically be the raw dump of the API endpoint's result.

So nothing will change for existing methods. This PR only adds new a new method (fetchSwapsFeatureFlags) and new interfaces (NetworkFeatureFlagsAll and NetworksFeatureStatusAll) that only apply to that new method.

[infiniteflower]

@infiniteflower just to double check, this does not rely in any way on previous patches, is that correct?

asking this since we are removing current ones on MetaMask/metamask-mobile#9286

It should be fine, it hits the same endpoint but just doesn't modify the endpoint results like the other function (fetchSwapsFeatureLiveness)