Add definitions for event reporting opt in headers

[blu25]

This issue was brought up in #158.

This PR adds official definitions for the Allow-Fenced-Frame-Automatic-Beacons and the Allow-Cross-Origin-Event-Reporting response headers that are used for cross-origin opt in for their respective features.

---

Preview | Diff

[cbiesinger]

I'm curious, why is this a structured header with a string "true" or "false" instead of a boolean structured header?

[blu25]

I'm curious, why is this a structured header with a string "true" or "false" instead of a boolean structured header?

The implementation of this expects string literals (true/false) rather than boolean values (?0/?1). I wasn't aware of the precedent set in RFC8941 at the time, and I had copied the syntax of an existing flag that was also not using the boolean convention when I had implemented this feature. Since the code is already in place, and since changing this to a boolean would delay getting this feature out by at least a month, I think it's better to keep the implementation as is and make sure the spec matches the implementation.

[miketaylr]

would delay getting this feature out by at least a month

As far as long-term web platform health is concerned - 1 month is basically nothing. Any other compelling reasons to not do this work?

[shivanigithub]

As far as long-term web platform health is concerned - 1 month is basically nothing. Any other compelling reasons to not do this work?

Update: The team is proceeding with the change to boolean: https://chromium-review.googlesource.com/c/chromium/src/+/5542760

[miketaylr]

LGTM, with some take-em-or-leave-em nits.