Draft code to add TlsConnect trait

[zh-jq-b]

See #2137

I add a TlsConnect trait in this draft PR, it will be possible for users to use other tls crates to do DoT or DoH.

What do you think about this?

[djc]

I've skimmed this and I wonder if all of this complexity is necessary. I feel like we should rebuild the network stuff to lean more heavily on dynamic dispatch, bridging directly from RuntimeProvider to something like a Pin<Box<dyn Future<Output = Pin<Box<dyn Stream<Item = Result<DnsResponse, ProtoError>>>>>>>.

[bluejekyll]

@djc, I think that might be beyond the scope of the motivation for this change?

@zh-jq-b This seems inline with the existing design I think. At least for the standard socket stuff, this should work. I think there's a lot of complexity with what happens with quic and h3.

[zh-jq-b]

This seems inline with the existing design I think.

Yes, the current rustls/openssl/native-tls feature can be changed to this way, and then DoH can make use of them. I can try to prepare a PR if you think it's acceptable.

At least for the standard socket stuff, this should work. I think there's a lot of complexity with what happens with quic and h3.

Yes. This can be delayed after the TLS part get resolved.