Clarify retry semantics w.r.t. HTTP auth and redirects

[cfredric]

Since the Activate-Storage-Access: retry header can be provided on any HTTP response, it's possible to provide it on a response that would otherwise be considered an HTTP redirect (3xx w/ Location) or HTTP auth challenge (401 w/ WWW-Authenticate). We should therefore be explicit about how the retry is handled relative to both auth and redirects.

Idea

Redirects

In order to allow servers to achieve any kind of fallback behavior in clients that do not support Storage Access Headers, the browser should handle Activate-Storage-Access: retry before handling redirects. That way, a server can respond with a 3xx redirect and include the retry token, and know that some browsers will retry the request (with unpartitioned cookies), and some browsers will follow the redirect.

Auth

Auth is slightly more sensitive, due to the possibility of auth responses from proxies. A proxy may respond with an auth challenge (and include the retry token), but in such a case, we want to honor the auth semantics before retrying the request. So, the browser should handle auth challenges before looking for the retry token.

If these semantics seem reasonable to folks, I'll include them in the eventual spec for this proposal.