Support Widevine in Arm64 Brave on Windows

[mherrmann]

Resolves brave/brave-browser#28318.

Notes to reviewers

The design of the implementation is described in the newly-added file brave/browser/widevine/README.md, under section Widevine in Arm64 Brave on Windows: WIDEVINE_ARM64_DLL_FIX. The easiest way to review the code is to read the explanations there, reviewing the mentioned files as you go along.

Submitter Checklist:

• I have requested a privacy review.
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
• 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 wiki
  • npm run lint, npm run presubmit wiki, 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:

Please test that Arm64 Brave on (Arm64) Windows can successfully install the Widevine component and play DRM-protected content at the highest quality.

To check for regressions, please test that Widevine can still be installed and DRM-protected content can still be streamed at the highest quality on Windows and macOS. See for example brave/brave-browser#29469 (comment) for some good tests for checking the video quality.

All tests should be performed with a clean profile. On Windows for example, this means deleting (or temporarily renaming) the %LOCALAPPDATA%\BraveSoftware\Brave-Browser-<channel>\User Data directory. The reason why the profile should be clean is that an existing profile might have already installed the Widevine module.

[fmarier]

I did not do a thorough line-by-line review, but the only security-relevant change I asked for after looking through the code has been fixed.

[iefremov]

unlocking browser/net/*, patches and chromium_src need some more work as discussed

[mherrmann]

For my own reference: There's now version 4.10.2662.3 in https://dl.google.com/widevine-cdm/versions.txt. This PR may need to be updated.

[ilina-linaro]

Thank you for your patch @mherrmann. We @ Linaro are actively watching the progress on this support and this patch.

[ilina-linaro]

Thank you all for the progress. Is there a binary I can try? I tried building, but ran into compilation issues after many hours of build on my Windows on Arm box.. Haven't gotten around to fixing that, but an installer would be great.

[mherrmann]

@ilina-linaro once this PR is merged, you should be able to get binaries from Brave's next Nightly release on the GitHub releases page. I normally use BraveBrowserStandaloneNightlySetupArm64.exe.

[bridiver]

why did we add a second copy of this method instead of using buildflags around the params? It's very confusing, especially because the two methods are not even together in the file. This one also has a VLOG that the other one doesn't

[mherrmann]

The motivation was to split this source file into two clean halves: One with BUILDFLAG(WIDEVINE_ARM64_DLL_FIX) and the other one without. It felt easier / clearer when implementing this PR. But I can see now that for example when searching for the definition of the function, it is less clear to see which definition will get used. Do you want me to file a follow-up PR that refactors this?