resolver: err for dns-over-rustls w/o roots

[cpu]

If we're setting up dns-over-rustls and find that we've constructed a Rustls root cert store that has no trust anchors, return an early error. This makes the problem obvious and avoids surfacing some other less specific error cause when we first try to validate a peer certificate with an empty root store.

In order for our new early error to be surfaced correctly the name_sever_pool.rs parallel_conn_loop fn needs its error handling adjusted. Previously it would always compare the new error produced by trying to build the TLS config against the default error it starts its loop with, ProtoErrorKind::NoConnections. Since the error being returned is another ProtoErrorKind that isn't NoRecordsFound, Io, or Timeout the error specificity comparison considers the two errors equivalent in the general case, and the default error was always returned and the new error thrown away.

There is still a small mystery around why a more specific error from tokio-rustls isn't returned when peer validation inevitably fails. In my testing upstream we get a nice io::Error like err: Custom { kind: InvalidData, error: InvalidCertificate(UnknownIssuer) }. I can't figure out where or why, but something in the Hickory DNS stack is reducing this down to just a simple io error with type InvalidData - no nested source error or message. See my comment here I think this is a side-effect of the Clone impl on ProtoErrorKind.

Updates #2066

[cpu]

There is still a small mystery around why a more specific error from tokio-rustls isn't returned when peer validation inevitably fails.

Now addressed separately in #2181

[djc]

Thanks!