HTTPS-RR upgrades are in the wrong place

[davidben]

I was going to leave this as a comment to #1426, but that is about making HSTS use a synthesized redirect, and this is about a DNS-level upgrade:

For HTTPS-RR, it's actually already defined as a synthesized redirect:
https://www.rfc-editor.org/rfc/rfc9460.html#name-http-strict-transport-secur

Fetch's attempt to respecify this also seems to be wrong because this position would suggest it happens before Service Workers or HTTP caching happens or anything! Respecifying it is also problematic because RFC 9460 contains a ton of other machinery that we wouldn't want to respecify.

Looking at where to put it instead, the natural place would be to just add to this line in HTTP-network fetch.

But the problem is Fetch tries to specify connection management in detail, even though this isn't really accurate given things like QUIC, Happy Eyeballs v2 and the upcoming Happy Eyeballs v3. So it's hard to just defer to the HTTPS/SVCB RFC in its entirety. I think we'd need to defer to more IETF documents in connection management, or continue to respecify things. I would much prefer the former, to reduce all this duplicate busywork, but I suspect the latter is easier for now.

The way we do this in Chrome is that our DNS lookup machinery, if it sees an HTTPS record when we're making an HTTP fetch, we return a special error that the HTTP layer catches to synthesize a redirect. That's probably the right way to model it in Fetch as well. We'd have to tweak resolve an origin and a couple of its callers up the stack.