Update real time reporting explainer.

[qingxinwu]

There are 4 main updates we’re making to the explainer:

1. The real time reporting API surface. (1) combining contributeToRealTimeHistogram() and contributeOnWorkletLatency() APIs into a single API contributeToHistogram(). (2) moving the first parameter (bucket) to the API’s single argument (which is an object), as a required field of the argument object.
2. Define and support platform contributions, which are not visible in either scoreAd() or generateBid(). Currently 4 platform contributions are supported: bidding/scoring script fetch failures, trusted bidding/scoring signal fetch failures.
3. Changed format of the report which is sent as a network request body. (1) Changed its content type from JSON to Cbor (2) a single vector of 0/1s, to a map with data version, and separate user contributions and platform contributions to two fields.
4. Rate limit sending real time reports to 10 reports per reporting origin per page per 20 seconds (per browser), to mitigate a privacy risk.

[dmdabbs]

A 304 (Not Modified) would be considered an error?

[qingxinwu]

yes. Non-2xx codes will be considered as errors.
See step 2 of spec: https://wicg.github.io/turtledove/#validate-fetching-response-headers

[dmdabbs]

Bidding and scoring scripts (versus the dynamic signals) are expected to be slowly changing and adtechs will count on browsers' HTTP cache.
Not modified (304) is not an error status:

A null body status is a [status](https://fetch.spec.whatwg.org/#concept-status) that is 101, 103, 204, 205, or 304.

[qingxinwu]

Here is the code that checks for the header to be 2xx.
@morlovich knows the network related code better. @morlovich would you mind helping here?

[morlovich]

I think you normally won't see a 304 at this layer, but rather the cached response (with updated headers).

Probably this stuff:
https://fetch.spec.whatwg.org/#:~:text=If%20the%20revalidatingFlag%20is%20set%20and%20forwardResponse%E2%80%99s%20status%20is%20304%2C%20then%3A