Fix widevine install prompt is shown after using new profiles

[simonhong]

Fix brave/brave-browser#6747

Install prompt is displayed if widevine is opt opted in by user and user
doesn't choose don't ask option of it.

Widevine cdm lib is loaded into cdm utility process after it installed.
And it is browser widely used not just for specific profile.
However, Brave has prompted widevine permission prompt when user loads
contents site(ex, netflix) in newly created profile.
If Widevine cdm lib is already installed by any profile, Brave should not
display it again because cdm lib is already used.

To fix this, two kWidevineOptedIn/kWidevineInstalledVersion are migrated
from profile prefs to local state.
When migration is needed, firstly active profile is used to get existing
pref values.

There is one more Widevine related pref. It's kAskWidevineInstall.
It would be good to migrate kAskWidevineInstall to local prefs also.
But left as-is in profile prefs also seems fine.
After Widevine is installed that prefs doesn't have much meaning and if not just click once to dont ask is sufficient. Also, it is convinient to implement settings option with profile prefs.

Submitter Checklist:

• Submitted a ticket for my issue if one did not already exist.
• Used Github auto-closing keywords in the commit message.
• Added/updated tests for this change (for new code or code which already has tests).
• Verified that these changes build without errors on
  • Android
  • iOS
  • Linux
  • macOS
  • Windows
• Verified that these changes pass automated tests (unit, browser, security tests) on
  • iOS
  • Linux
  • macOS
  • Windows
• Verified that all lint errors/warnings are resolved (npm run lint)
• Ran git rebase master (if needed).
• Ran git rebase -i to squash commits (if needed).
• Tagged reviewers and labelled the pull request as needed.
• Request a security/privacy review as needed.
• Add appropriate QA labels (QA/Yes or QA/No) to include the closed issue in milestone
• Public documentation has been updated as necessary. 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-Protection-Mode
  • 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-issues-with-tracking-protection
  • https://github.com/brave/brave-browser/wiki/QA-Guide

Test Plan:

yarn test brave_browser_tests --filter=*Widevine*
yarn test brave_unit_tests --filter=*Widevine*

Migration test steps

1. Launch previous browser(that doesn't include this fix)
2. Install Widevine and exit
3. Launch latest browser that includes this fix
4. Check Widevine install prompt is not displayed in default profile and any newly created profiles

Reviewer Checklist:

• New files have MPL-2.0 license header.
• Request a security/privacy review as needed.
• Adequate test coverage exists to prevent regressions
• Verify test plan is specified in PR before merging to source

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.

[simonhong]

CI looks good with current commit. So, added skip tag.
After reviewing, will remove skip tag.

[bridiver]

this should just be ENABLE_WIDEVINE

[simonhong]

Last CI build was success and pushed one more commit for just adding comments.

[darkdh]

Is it possible to add a PRE_PrefMigrationTest and set local_state to default value and also set profile value for kWidevineOptedIn and kWidevineInstalledVersion to verify the migrated values?

[simonhong]

I tried that scenario at first.
But, local_state is not the default value at the second launching.(Of course, cleared local state in the first launching).
Not sure why it happens. I'm trying again.

[simonhong]

Hmm, local state seems not consistent during the spanning tests.
In the second launching, it's state is not the last state of first browser launching.
profile prefs shows consistent state but not local state during the spanning test.

[simonhong]

local state is persisted but not persisted after clearing prefs(ClearPref()).
At second test, local state has the value before the clearing. I expected it has default value because ClearePref() is called but it's not default value at second test.
So, testing is done by explicitly calling MigrateWidevinePrefs() instead of spanning test.