Reconfigure Rewards component folder structure

[zenparsing]

Resolves brave/brave-browser#34881

Summary:

• Since iOS also uses this code (and we may move the iOS drivers into this folder at a later time), a "layer component" structure has been used.
• Since there is no renderer code, browser process code is placed directly in the top-level folders.
• This is a rename-only PR, with the exception of some minimal changes required to pass presubmit checks.

Changes:

• components/brave_rewards/browser => components/brave_rewards/content
• components/brave_rewards/browser/test => browser/brave_rewards/test
• components/brave_rewards/common => components/brave_rewards/core

Submitter Checklist:

• I confirm that no security/privacy review is needed and no other type of reviews are needed, or that I have requested them
• 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 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/Web-Compatibility-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Test Plan:

[brave-builds]

A Storybook has been deployed to preview UI for the latest push

[github-actions]

Chromium major version is behind target branch (132.0.6834.83 vs 133.0.6943.27). Please rebase.

[tmancey]

Ads LGTM++

[bridiver]

you still have common here which is a process directory, but not sure what makes sense here instead

[zenparsing]

That folder contains utility functions and classes for use by the "engine". The folder could be renamed to "util" or "helpers" or something similar.

[bridiver]

either of those options are fine, I just don't want to confuse the use of common due to its special meaning in chromium

[bridiver]

This seems odd, internal code shouldn't be accessible outside of the component. This would also allow subdirectories inside core/internal. Maybe this should have a different directory name or maybe whatever files you need in browser/brave_rewards should go somewhere else?

[zenparsing]

In browser/brave_rewards/android/brave_rewards_native_worker.cc we have the following usage:

brave_rewards::internal::constant::kWalletSolana

This is the only usage of internal in this folder. Ideally, I think that the constant should be moved out of internal and (optionally) it should be an enum value instead.

[bridiver]

Right, this is why I suggested moving things that are shared out of internal, but it seems like this PR is moving a lot of things into internal? In any case I think it's best to limit this PR to fixing of layered component directory issues and follow-up with other changes to keep the size/scope of this PR down

[bridiver]

This is good to move these out of components and I guess you could consider it part of fixing the directory structure, but this PR is a bit large so maybe this should be split out? Also please remove the specific include rules for these in DEPS

[bridiver]

why does this need to be added?

[zenparsing]

This presubmit checks tries to find mojo interfaces that have (accidentally) changed. When mojom files are moved, the check frequently throws an error because it can't find the "old" file. After this PR is merged, we can remove these lines.

[bridiver]

similar to the earlier comment making something in internal a public_dep here seems odd. Also this particular target didn't have a directory structure issue once the process directories were removed so why move it to internal?

[zenparsing]

Background on internal (currently core):

This is the cross-platform "Rewards engine" code that currently runs in a utility process on desktop/android, but could potentially run in the browser process in the future. It was originally in third_party/bat-native-ledger I think.

It seems to me that ideally this folder would be truly internal, and it would only be accessed by iOS or content drivers also in components/brave_rewards. If we want to move in that direction, then internal as the folder name makes sense, and I can gradually move us there.

Alternatively, we could name this something like "engine".

[bridiver]

buildflags are internal? I think the whole internal thing is confusing this PR a bit and doesn't seem necessary for fixing the issues with the component directory structure so that should probably also move to a separate PR

[zenparsing]

This is odd, I agree (and it was odd even without the internal name). Can this target be moved into the already existing components/brave_rewards/core/buildflags target?

[github-actions]

[puLL-Merge] - brave/brave-core@27270

Description

This PR reorganizes the brave_rewards component by splitting it into three main parts:

1. browser - Browser-side implementation and UI logic
2. common - Common code shared between browser and renderer processes, including mojom interfaces and preference definitions
3. core - Core rewards engine implementation (mostly unchanged)

The main motivation appears to be better code organization and separation of concerns between the browser, common, and core components.

Changes

Changes

By filename pattern:

Common Files Moved/Renamed (core -> common)

• Moved mojom definitions and buildflags
• Moved preference definitions and registries
• Moved common utilities and feature flags

Browser Files Moved/Renamed (content -> browser)

• Moved browser-side implementation classes
• Moved rewards service implementation
• Moved notification service implementation
• Moved UI/WebUI code

Test Files Reorganized

• Consolidated test utilities under browser/test/common
• Moved browser tests to appropriate directories
• Updated test dependencies and includes

sequenceDiagram
    participant Browser
    participant Common
    participant Core
    Browser->>Common: Uses shared definitions/interfaces
    Browser->>Core: Interacts with rewards engine
    Core->>Common: Uses shared types/constants

Loading

Security Hotspots

1. The changes to mojom interface locations require updating security review restrictions and interface stability checks to ensure secure IPC communication.

2. Moving preference definitions could impact security-sensitive settings if proper migration and validation isn't maintained during the reorganization.