accept insecure TLS state seems badly specified

[gsnedders]

https://w3c.github.io/webdriver/#dfn-post-navigation-checks contains:

response is blocked by content security policy

If the remote end's accept insecure TLS state is true, take implementation specific steps to ensure the navigation is not aborted and that the untrusted or invalid TLS certificate error that would normally occur under these circumstances, are suppressed.

Otherwise return error with error code insecure certificate.

This seems to originate from https://github.com/w3c/webdriver/commit/321fff4e12d80a745828f7c711fdc18932cca244 (from https://github.com/w3c/webdriver/pull/337).

As far as I can tell, what we're actually trying to override is the nebulous "if establishing a connection does not succeed (e.g., a UDP, TCP, or TLS error), then return failure" in https://fetch.spec.whatwg.org/#create-a-connection which ultimately gets surfaced as a network error. Fetch calls into the CSP to determine whether or not certain requests should be blocked, but TLS connection errors aren't one of them.

This should presumably be under "response is a network error" instead.

However, this doesn't make sense to have as a post-navigation step.

If Fetch is failing with a network error while it is creating a connection, it is not even reaching a point of actually making an HTTP request. Thus while navigation will complete, it will have already hit the network error when creating the connection. It is unclear how after the navigation (assuming it hasn't timed out) the implementation can "take implementation specific steps to ensure the navigation is not aborted and that the untrusted or invalid TLS certificate error that would normally occur under these circumstances, are suppressed".

[gsnedders]

See also #1806, given we don't really know what response we're looking at.

With accept insecure TLS we probably want to actually just override behaviour for all fetch requests?