[WIP] Disable Brave Shields + extension on navigation error

[ShivanKaul]

(Wanted to run the approach by folks first.)
We added a fingerprinting strict protection where we disable dark mode. We shouldn't apply that on 'internal' pages (for e.g. brave://settings, error pages). The brave:// URL case is taken care of by checking for Brave Shields being up, but turns out that on error pages (no wifi, no DNS) shields is still up, which breaks dark mode on error pages.

In this PR, my current (faulty) approach to fix this is:

1. Watch for onErrorOccurred event fromwebNavigation
2. Set a new boolean error on the Tab.
3. Set the old value of Shields (up or down) for that origin on the Tab
4. Set shields to be down for that origin
5. Now, when the event onCommitted fires, check if the current tab has an error. If yes, clear the error, check the old value of shields set on the Tab and set the old value of Shields on the current origin

This is flawed, because Brave Shields being up or down is an origin concept, while the browser action is a tab concept. So we need to store the old (correct) value of Brave Shields for that origin somewhere else (not on the Tab). I could create a new map of {origin => braveShieldValues} but I think that would lead to a problem where the user goes to https://twitter.com, has their wifi off, the Shields is set to down and {'twitter.com' : 'up'} is stored in memory, but the user now quits the browser. Next time they relaunch and go to https://twitter.com, there would be no in-memory map and they would see the Shields being down even though their wifi is now working.

In general, this approach seems pretty complicated. Am I missing something, is there an easier way to do this?

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:

[petemill]

isNavigationError perhaps is clearer

[petemill]

hmm yes I'm wondering if we should instead "do nothing" in the c++ layer of brave shields. The panel should only be concerned with whether or not it shows the shields settings or not for the current tab.

[ShivanKaul]

@petemill my initial approach (after talking to @pilgrim-brave) was to override the error interstitial creation method in Chromium to disable Brave Shields (using brave_shields::SetBraveShieldsEnabled), but that would disable it permanently for the URL (same issue) - and then when would we reset the Shields to the old up/down value for the URL?
Plus, ideally we'd want to disable the extension's browser action (make it unclickable) as well, so the extension has to have some way of knowing that we're on an error page.