Start ledger process and load extension (if needed) before opening Rewards panel

[emerick]

Resolves brave/brave-browser#21311

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
• 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, 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:

[bsclifton]

Code here LGTM! 😄

I had deleted some comments when thinking things through; I was thinking to self, "maybe add pref_change_registrar check for ads preference too (similar to BraveComponentLoader::CheckRewardsStatus)"... but that felt like a hacky suggestion

One thought I did have though EnsureBrowserContextKeyedServiceFactoriesBuilt gets called at profile creation. We could add the call to AddRewardsExtension in the RewardsServiceFactory (ex: inside BuildServiceInstanceFor)

[zenparsing]

@bsclifton I agree that extension loading should be managed from one place in the code. Unfortunately, as we've baked more UI into the rewards extension, we've added more paths that need the extension loaded. Ultimately though, we'll want to stop using the extension for the panel altogether.

[emerick]

@bsclifton @zenparsing If it's OK, I'm going to keep this as-is since the current change is completely isolated to adaptive captcha (that code isn't called from anywhere else) and we want to uplift this into 1.36 ASAP. The Rewards team is meeting today, so I can bring up the long-term plans for extension management (or discuss whether the extension just goes away) at that meeting. Will follow up here with a pointer to issues, etc. post-meeting!

[kjozwiak]

Verification PASSED on Win 11 x64 using the following build(s):

Brave | 1.38.6 Chromium: 99.0.4844.45 (Official Build) nightly (64-bit)
-- | --
Revision | edbc0b8343c7b10fddb0e1b4efb280b0f6e38cab-refs/branch-heads/4844@{#788}
OS | Windows 11 Version 21H2 (Build 22000.527)

Verification notes can be found via https://github.com/brave/internal/issues/857#issuecomment-1053884823.