Add render-blocking boolean to fetch timing info

[abinpaul1]

These changes are to support addition of a render blocking status field to Perfomance resource timing. Further details are available at w3c/resource-timing#327

For HTML side changes see whatwg/html#7979

• At least two implementers are interested (and none opposed):
  • Chromium : https://chromestatus.com/feature/5166965277589504
  • Firefox : Render blocking status in Resource Timing mozilla/standards-positions#662 (comment)
• Tests are written and can be reviewed and commented upon at:
  • https://chromium-review.googlesource.com/c/chromium/src/+/3709521
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1337256
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1799493
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=247572
  • Deno (not for CORS changes): …

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[yoavweiss]

I think it'd be better if this used the existing Request's render-blocking boolean. For that, I think you need to pass it with the request itself, and not when finalizing the response. Apologies for not catching that earlier.

/cc @xiaochengh for thoughts

[xiaochengh]

I added Request's "render-blocking" as a boolean because I felt the multivalue enum is too Blink-specific.

Here, do we still want to put a multivalue enum on Request (like what Blink currently does), or just use the existing boolean?

[annevk]

Note that once @noamr's #1413 lands this will have to change somewhat significantly. And I suggest we land that first as it's a rather big change and it seems relatively straightforward to adjust this.

[abinpaul1]

I've updated this to use Request's render-blocking boolean and also adjusted for #1413 changes

[annevk]

Looks okay modulo this nit. If this suggested change looks okay I'd be happy for @domenic to land this as I'll be away for the next couple weeks.