Add support for default feature state overrides using static map

[goodov]

Resolves brave/brave-browser#18829

Submitter Checklist:

• I confirm that no security/privacy review is needed, or that I have requested one
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
• Checked the PR locally: npm run test -- brave_browser_tests, npm run test -- brave_unit_tests, npm run lint, npm run gn_check, npm run tslint
• Ran git rebase master (if needed)

Reviewer Checklist:

• A security review is not needed, or a link to one is included in the PR description
• New files have MPL-2.0 license header
• Adequate test coverage exists to prevent regressions
• Major classes, functions and non-trivial code blocks are well-commented
• Changes in component dependencies are properly reflected in gn
• Code follows the style guide
• Test plan is specified in PR before merging

After-merge Checklist:

• The associated issue milestone is set to the smallest version that the
  changes has landed on
• All relevant documentation has been updated, for instance:
  • https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)
  • https://github.com/brave/brave-browser/wiki/Proxy-redirected-URLs
  • https://github.com/brave/brave-browser/wiki/Fingerprinting-Protections
  • https://github.com/brave/brave-browser/wiki/Brave%E2%80%99s-Use-of-Referral-Codes
  • https://github.com/brave/brave-browser/wiki/Custom-Headers
  • https://github.com/brave/brave-browser/wiki/Web-Compatibility-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Test Plan:

[mariospr]

JFTR: I've checked all enabled features one by one to confirm all were properly migrated and that seems to be the case 👍

[mariospr]

JFTR: I've checked all disabled features one by one to confirm all were properly migrated and that seems to be the case 👍

[iefremov]

LGTM!

[goodov]

Sorry reviewers, I decided to went with a single macro which should be used to bulk-override all .cc-local features. This way the base::flat_map::sort_and_unique on insert will be called only once for each macro instantiation instead of for each feature override. And now only one macro instantiation is allowed in a .cc file.

Feel free to review once more. Sorry again :) I added this change as a new commit on top.

[goodov]

the way this macro should be used is intentional. If we put { or {{ inside the macro, then clang-format wouldn't be able to properly format lines which are #if defined(...). Example:

OVERRIDE_FEATURE_DEFAULT_STATES({
  {kReadLater, base::FEATURE_DISABLED_BY_DEFAULT},
#if defined(OS_ANDROID)
      {kReadLater2, base::FEATURE_DISABLED_BY_DEFAULT},
#endif
      {kReadLater3, base::FEATURE_DISABLED_BY_DEFAULT},
});

[mariospr]

LGTM (also liked the latest changes 👍 )

[mkarolin]

I am probably missing something obvious here, but why do this via a class and construct all those global objects instead of using a global function to populate the map?

[goodov]

The question is at what point you have to populate the map and how to make sure it will happen in all processes. The global construction approach make it so in each process (utility, renderer, etc), the map is populated at the very start regardless of what Chromium/Brave delegate is called or not.

[mkarolin]

Oh I see, yep, that totally makes sense. 👍

[mkarolin]

++