Deliver P2A metrics to the same endpoint at P3A

[rillian]

Description

We introduced a temporary "P2A" metrics endpoint to measure ad interaction opportunities. This overloads the normal P3A usage data reporting mechanism with some additional privacy protections to handle this level 3 data:

• Responses are limited to 2 answers (vs 8 for P3A)
• Responses have random noise added for local differential privacy
• We do not collect the submission's IP address

These techniques are generally applicable; it would be easier to treat them as an optional step applied to some P3A measurements instead of using a separate back-end. The creation of the new json reporting endpoint in #15967 is a good opportunity to start sending both metric streams to the same endpoint url, simplifying the client-side by more effectively making the current P2A metrics a variety of P3A data.

Proposed Design

Starting with the switch to json-formatted messages, we'd simple start reporting Brave.P2A.* measurements to the same endpoint url as all other P3A messages.

Initially we could continue to set the X-Brave-P2A and X-Brave-P3A variant headers to mark the difference, but the back-end should eventually sort based on the metric name alone.

We would need to verify that the p3a json endpoint proxy strips the client IP address so our organization cannot associate it with any particular submission.

[rillian]

CC @porteron @moritzhaller @iefremov.

The json endpoint was initially configured in brave/devops#6077

[porteron]

Should be fine on the reporting side of things. Right now we have separate collections in Redshift for p2a and p3a which will continue to be separate until we completely cutover to the new json format.

If the intention is to combine the future p3a and p2a data then we could aggregate together and consider them the same. As long as the convention is maintained that p2a questions are distinguishable by name then everything should work fine.

[rillian]

We've decided maintain distinct endpoints for P2A and P3A for now.

Closing this in favour of #22079.