Send P2A json messages to the P3A endpoint.

[rillian]

These are handled with the same reporting software and privacy
protections on the server-side, so there's no value to maintaining
a separate endpoint for the P2A message type. Instead, send them
all to p3a-json.brave.com and sort into the approprate queue
on the back end.

Resolves brave/brave-browser#20478

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:

Launch browser with a network proxy. Observe P2A messages being sent.

• protobuf-encoded messages should be sent to p2a.brave.com as before
• json-encoded messages should also be sent to p3a-json.brave.com alongside P3A messages (new behaviour)
• P2A messages can be identified by the Brave.P2A prefix in the metric name
• P2A messages should have the X-Brave-P2A http header set.

I'm not sure how to trigger P2A reporting. Maybe something like this would work?

• Launch browser
• Enable rewards
• Browse long enough for ads to be presented e.g. enable Brave News and scroll until an ad is shown, open new tabs until the new tab page shows a paid image, click on the embedded link.
• Confirm Brave.P2A metrics are listed under brave.p3a in brave://local-state
• If metrics have already been sent on the profile, advance system clock to midnight on a future Sunday night to trigger a new round of submissions. Sometimes I've been able to get a few P2A reports sent on first launch.
• Wait ~10 minutes for reports to be sent over the network.

[porteron]

@rillian I think there are a few implications here to consider.

1. How will questions be segmented in the logs?
   • I don't think they will be.
2. How much additional volume should we expect here?
   • Looking at previous weeks, we can expect p2a will add 114 Million requests/week to the p3a s3 logs.
3. If we consolidate logs we will also consolidate the reporting and aggregation.

[rillian]

Hi @porteron. Thanks for the additional traffic estimate. That's not insubstantial!

How will questions be segmented in the logs?

Earlier we'd discussed segmenting based on the metric name; all P2A reports are prefixed with Brave.P2A, which is what the client currently uses to choose the endpoint. Will that still work? I figured it would be ok to log them together, but have the ingest processing distribute the messages to the appropriate backend so the reporting can remain unchanged.

If you'd rather segment the logs themselves, the client still sets an X-Brave-P2A http header; maybe fastly could be configured to log to a separate bucket based on that?

As with the transition to P3A json, we'd have a period of transition with to make sure the new path was working.

[porteron]

@rillian If the p2a questions have "P2A." in the metric name then that should be fine. Just curious how much longer our reporting jobs will take with the increase in volume. If the plan is to report p2a with p3a anyways then this makes sense. Just wanted to raise those initial points.

[rillian]

@porteron Yes, thanks for raising them! Are you ok with the PR otherwise? We should see a slow ramp-up in load over a couple of months as the change migrates from nightly to release, like we did with the json P3A.

[porteron]

Looks good!

[rillian]

We've decided to keep the endpoints separate for now.