Fetch based design as a considered alternative

[yoavweiss]

When working on Pending Beacon, we got feedback that the design should be as close to fetch() as possible. There are parallels here, so I'm filing this issue as means to think through the implications of that alternative design.

A few differences between fetch()/PendingBeacon and this API:

• It's an anti-goal here to give the developer any control over when reports are being sent or knowledge that they were sent
• The reports are sent to very specific end-points, and not to any arbitrary reporting end-point
• The report's input is extremely specific (an array of PAHistogramContributions), and not amenable to fetch()'s general purpose sending
• There's no concept of a response (even though that's similar for PendingBeacon)

Given all the above, I think it makes sense to not try to align this with fetch(). At the same time, it's worthwhile to document the reasoning.

[yoavweiss]

Talking to @noamr, another potential reason why this shouldn't be fetch() is that this API is to be called from environments where a "regular" fetch() shouldn't be available.

[noamr]

Yea this seems like an API more related to shared storage worklets and FLEDGE rather than having anything to do with general-purpose fetching.