fix(runtime/tls): handle invalid host for connectTls/startTls

[erik]

Tiny fix, converts a process-killing panic into a standard runtime error.

Before:

> await Deno.connectTls({hostname: '8.8.8.8', port: 443})
thread 'main' panicked at 'Invalid DNS lookup: InvalidDNSNameError', runtime/ops/tls.rs:208:45
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Object({"id": Number(2), "error": Object({"code": Number(-32000), "message": String("Execution context was destroyed.")})})', runtime/inspector.rs:978:8
stack backtrace:
...

After:

> await Deno.connectTls({hostname: '8.8.8.8', port: 443})
Uncaught Error: Invalid DNS lookup
    at processResponse (deno:core/core.js:213:11)
    at Object.jsonOpAsync (deno:core/core.js:230:12)
    at async Object.connectTls (deno:runtime/js/40_tls.js:32:17)
    at async <anonymous>:2:1

Fixes #9452.

[kt3k]

LGTM

[lucacasonato]

I'm not to happy about it being a generic Error - anyone have any suggestions what Deno.errors error could be used instead?

[erik]

There are a few other generic error references in the function already. If there's a good alternative available, I can update those as well

[lucacasonato]

Could you actually put the original rust error message into the generic_error too? Debugging the error in the JS side is very hard otherwise.

[erik]

@lucacasonato so in this case it seems there isn't a good rust error message to base it off of.

See here for the error type we're looking at: https://briansmith.org/rustdoc/src/webpki/name.rs.html#77-82

I could update the generic error message if you have a more clear message in mind.

[lucacasonato]

ditto

[bnoordhuis]

@erik is right that InvalidDNSNameError provides no further context. I suggest merging this as-is.

[lucacasonato]

LGTM then