feat: evaluate list of self supported protocols on team protocols update

[PatrykBuniX]

Description

Every time team (or backend) admin changes the list of supported protocols (in feature config) we want to also re-evaluate the list of self user's supported protocols. This PR adds this functionality. Every time we receive feature config update, and see that "mls" was the feature that had been updated, we compare the local list of current supported protocols stored locally in team config with the list received in "mls" feature config update. If supported protocols were changed, we re-evaluate the list of self supported protocols and update it on backend.

Checklist

• PR has been self reviewed by the author;
• Hard-to-understand areas of the code have been commented;
• If it is a core feature, unit tests have been added;

[codecov]

Codecov Report

Merging #15888 (7ea3ed1) into dev (77e81f7) will decrease coverage by 0.01%.
Report is 5 commits behind head on dev.
The diff coverage is 38.88%.

❗ Current head 7ea3ed1 differs from pull request most recent head 4bd40f6. Consider uploading reports for the commit 4bd40f6 to get more accurate results

@@            Coverage Diff             @@
##              dev   #15888      +/-   ##
==========================================
- Coverage   44.51%   44.50%   -0.01%     
==========================================
  Files         673      674       +1     
  Lines       22735    22755      +20     
  Branches     5170     5175       +5     
==========================================
+ Hits        10120    10127       +7     
- Misses      11321    11334      +13     
  Partials     1294     1294              

[atomrc]

suggestion: maybe we could just send the previous value rather than the entire feature config, WDYT?

[PatrykBuniX]

Well, I tried to do it but didn't manage to achieve it type-wise. When accessing prevFeatureList[event.name] at this point, the type will not be properly narrowed down to e.g. FeatureMLS (we don't know what's event.name at compile time, it's FEATURE_KEY type)

Event data is nicely tied to its name.

But we cannot tie specific feature to it by FEATURE_KEY at this point. It's still union of different features.

Maybe it's possible but i cannot find a way? Any ideas?

[atomrc]

ah nevermind we can probably change that later, no biggies here 👌

[atomrc]

question: Will this work when the entire feature list is updated (that happens, for example, once every 24h)?
We might need to account for this as well

[PatrykBuniX]

question: Will this work when the entire feature list is updated (that happens, for example, once every 24h)? We might need to account for this as well

@atomrc
How about emitting the event inside updateFeatureConfig method instead? This one is called in case of 24h timer as well.

EDIT: Nevermind, we don't have access to event there, I will just handle this case separately.