[Spec] Real time reporting

[qingxinwu]

Spec real time reporting.
Explainer: https://github.com/WICG/turtledove/blob/main/PA_real_time_monitoring.md

Also fixed a bug in the spec:
[=generate potentially multiple bids=] should return failure if fetching wasm failed.

---

Preview | Diff

[qingxinwu]

@morlovich Mind taking a look at this big PR? No need to review it all at once, we can go several rounds, whichever way you prefer.

[morlovich]

I am a little confused by the typing of the 3rd argument here.

[qingxinwu]

it's a [=list=] literal.

[morlovich]

LGTM

[qingxinwu]

LGTM

Thanks Maks!

@domfarolino PTAL. Thanks!

[domfarolino]

I honestly do not think I will have time to review this PR. It's pretty big and seems pretty complicated, and I am out of the office for a lot of July. One thing I will warn against though is fetching with no-cors. Now that we've already documented, in this spec, that it is bad and should be avoided, I think we should do whatever we can to ensure new requests are not doing that in both our implementation and spec. I'm hopeful we don't do that in the implementation.

Separately, I would encourage you to audit the members of the request like origin/client and so on. I noticed a request made by this PR doesn't set a client, and doesn't set an origin. This is invalid for Fetch, and will blow up. What are we doing implementation-wise? And can we avoid no-cors by setting an appropriate origin?

[qingxinwu]

@domfarolino

1. About no-cors, it reuses the same code as all other reporting requests, so the implementation will change them all when we make the change, instead of having a different code route for different kinds of requests. I'll follow up with @MattMenke2 to make a plan on making the code change. Will update more here about the plan, but I think that can be a non-blocker of this PR.
2. Right, it's set to frame origin (code). Updated.
   Most requests in the spec missed this field (it's due to when I first wrote those parts, I didn't understand that the fetch spec's origin was the same as our implementation's "request_initiator", where the fetch spec's initiator is a different thing). I'll send a separate PR to fix all wrong requests as well.

[qingxinwu]

Also, I totally agree that this PR is quite large and complicated, and it's impossible to review everything without knowing the design/implementation details of the API. Fortunately Maks reviewed most of my CLs related to this new feature, and did a full review of this PR.
This feature is similar to those like forDebuggingOnly or private aggregation, where we expose a method to worklets, then collect and send those requests after auction, so spec wise, it follows the same flow.
Do you think it's possible that you just do a quick glance at this, and see if there're any platform issues (like IDL, the comments you had about request's origin, no-cors, etc,.) or some obvious problems, and approve it depending on Maks' review of rest of the PR? @domfarolino

One question about spec: is it common or useful to link to explainer? For example, we have a full explainer for this feature, explaining everything with more details. Is it useful to link to it in the spec in the new real time reporting section?