[ResourceTiming]: Changing `nextHopProtocol` exposure to align with spec

Howdy!
[If you don't care about the Resource Timing API or information leakage
about cross-origin connections, feel free to disregard!]

I'm working to fix an issue in Chrome <http://crbug.com/1184726> where
we're divergent from the Resource Timing(RT) + Fetch specs. I wanted to get
some feedback from a wider audience w.r.t. how risky we think the change
will be and to give folks a heads-up that this change is in the works.

*The long-and-short of it is that `nextHopProtocol` will be
hidden-by-default for cross-origin resources.* This means it will behave the
same way
<https://www.w3.org/TR/resource-timing-2/#sec-cross-origin-resources> as
other, potentially sensitive, fields returned through the RT API. Instead
of seeing things like "http/1.1" or "h2", the empty string will be returned
to prevent information about cross-origin connection types 'leaking'. As
with other RT attributes, HTTP responses can include a Timing-Allow-Origin
header <https://www.w3.org/TR/resource-timing-2/#sec-timing-allow-origin> to
allow the information to be shared to cross-origin requesters (useful for
CDNs and the like to help customers understand performance).

I'll be following up with other browser vendors to make sure each
implementation is consistent with the spec and each other. I can't speak to
if/when they'll adopt this approach but I hope to introduce the new
behaviour in Chrome M99. M99 is scheduled for Beta on February 3rd and
Stable on March 1st.

Does anyone think such a change will introduce significant breakage? I
imagine there isn't much content that would rely on `nextHopProtocol` (or
other Resource Timing values, for that matter) but folks that collect RT
data (say, Real User Metrics providers) probably do collect these values.
Apart from seeing a shift in data/dashboards, do we expect
pipelines/use-cases to break here?

Let me know if you have any questions/concerns/feedback!

Thanks,
- Tom

For the curious:
There used to be a special case in Resource Timing for how the
`nextHopProtocol` attribute was exposed across origin boundaries. The
cross-origin protection was only applied in the case where the resource was
being fetched for a `document destination` (think iframes, etc). So, today,
'example1.com' could request an image resource from 'example2.com' and
learn the `nextHopProtocol` value without 'example2.com's "permission".