WPT tests for security features applied to speculation rules ruleset fetch - #43488

…fetch

This adds WPT coverage for the fetch of the speculation rules
themselves (via the `Speculation-Rules` header). These are fairly
standard in how they work, but because these requests are currently
triggered only via a response header, they don't mesh very well with
the existing test harness for several reasons:

1. We need to make a new context to issue the request. A window
   works most naturally, since a UA might not bother fetching rules
   in a subframe).

   This has knock-on consequences, like the need to replicate the
   headers for the security features to this opened window, which
   is awkward because what these headers were isn't plumbed in yet
   and isn't easy to obtain from script.

2. Since this isn't requested via an element or script API, there
   is currently no explicit signal when this request has completed,
   successfully or otherwise. Instead, we poll the server to see
   when it has processed the request, timing out after some time
   if the request has not been seen (this is expected in the case
   that it is blocked).

   This has the potential to be flaky, though some steps are taken
   to mitigate this (and further ones could be, like using a longer
   or infinite timeout when the request should be allowed, but this
   requires plumbing the expected result deeper, which is awkward
   with the test generation machinery).

3. Since it is processed as a response header early in the
   lifecycle of the document, we can't rely on
   securitypolicyviolation events to be fired in that context with
   any determinism. In theory this could be worked around by having
   the server process violation reports but this has its own issues.
   Instead they're skipped here, but not in an elegant way.

Bug: 1507833
Change-Id: I3e5de39191241ebee592c8e9ea85e38f462e1d7c