Allow intercepts to provide a list of known network error types

[jgraham]

The main work here is to work out what the specific types of error we can talk about in a cross-browser way. Once we have that, most of the actual behaviour is defined by the implementation's network stack.

[thiagowfx]

CDP reference (could be used as a starting point for a subset of errors): https://chromedevtools.github.io/devtools-protocol/tot/Network/#type-ErrorReason

Allowed Values: Failed, Aborted, TimedOut, AccessDenied, ConnectionClosed, ConnectionReset, ConnectionRefused, ConnectionAborted, ConnectionFailed, NameNotResolved, InternetDisconnected, AddressUnreachable, BlockedByClient, BlockedByResponse

[Lightning00Blade]

@jgraham I looked a little bit in this.
A good starting point can be Aborted one as that has reference in the Fetch spec.
And it translates to user has aborted the request (via AbortController).

All the other CDP accepted strings look like TCP errors.
There seems to be no list of them on the TCP spec itself.

The CDP map is defined here and all network errors here

Another spec that uses TCP errors - https://www.w3.org/TR/network-error-logging/#secure-connection-establishment-errors also does not link back to the spec.

With this in mind I think we should agree on a sub-set that of them or define them as string with a optional if implementation does not support it throw "unsupported operation" error.