Improve Developer Experience for expects_no_vary_search in Speculation Rules

[0xZOne]

Per https://github.com/WICG/nav-speculation/blob/main/triggers.md#no-vary-search-hint:

We would like preloading to make use of the improved matching enabled by the No-Vary-Search HTTP response header. When the user agent gets the response to a preloading request, it can make use of the No-Vary-Search, if present, when deciding whether to serve a subsequent navigation with the preload. However, if there is an ongoing preloading request for which the user agent has not yet received the response headers, we would need to make a tradeoff.

To solve this, we have the speculation rules syntax provide a hint for what the author expects the No-Vary-Search value to be. A rule may have an "expects_no_vary_search" field which has the expected header value as a string.

This implementation requires changes on both the front-end and server sides. Front-end developers need to add the expects_no_vary_search field in the speculation rules, while back-end developers must implement the No-Vary-Search header on the server.

If the server does NOT include a No-Vary-Search header in the response to a prerendering request, the expects_no_vary_search option in the speculation rules will not take effect, and successfully prerendered pages will be wasted.

However, Front-end developers and back-end developers are often separate groups of people working in different teams.

Here is a minor adjustment I'd like to propose:

If the response includes a No-Vary-Search header, maintain the existing logic. However, if the response is missing this header, use the expects_no_vary_search value from the speculation rules to match the preload cache.

[jeremyroman]

The tricky thing here is that affecting the cache treatment of resources is usually something the server controls, for a number of reasons, including that the client's expectation may be out of date, and especially for cross-origin requests, might be controlled by a separate entity.

Ultimately what's being made here is an assertion about what parameters the server does and does not use to control its response, so allowing a client to backfill that is tricky (though there is some precedent in some cases, like SW fetch interception) and certainly shouldn't be implicit.