Removed attempt to connect to server info host when TLS is enabled

[brooksmtownsend]

After some back and forth with @Jarema , I was having some trouble connecting to connect.ngs.global with the nats client. I was getting an error for UnsupportedNameType, which I tracked down in rustls. When I took a look at this function, it seems that attempting to connect to NGS always resulted in the info.host variable filled in as an IP address, which as you can see in the above function creates an error.

Simply removing this fixes the issue for me but I wanted to open this PR for discussion. I'm not entirely sure if connecting to an IP address with TLS is a totally valid use case, or if ignoring the info.host value here is the proper solution. What also worked for me is reordering the connections to try creating a server name from tls_host first, but that's not really solving much more than just removing the option.

Anyways, looking forward to discussing this. If we wanted to make this a bit more robust, I can create a ServerName from both values and match to ensure that the value is a ServerName::DnsName rather than just taking tls_host

[philpennock]

The correct behavior, for the NATS protocol, per the Go behavior is: if you connected to a NATS server with a DNS hostname, and the server advertises reconnection URLs to you which use IP addresses, then reuse the original hostname as the verification hostname: that has to remain valid across reconnection attempts. Only change the hostname which you validate if the server gave you a connection address which has a hostname in it.

[brooksmtownsend]

Addressed @philpennock's note in my latest commit, the behavior is

1. parse hostname that we validate if the server gives us a new hostname
2. fallback to tls hostname IF it's a DNS hostname
3. error if not

Note that as far as I can tell, this new logic will prevent TLS connections to IP addresses at the async_nats layer, but regardless it's an error as specified above in the rustls library so it couldn't go through either way.

[philpennock]

LGTM as someone who knows about NATS/security/TLS, but I'm carefully not approving as I'm not a nats.rs owner.

[caspervonb]

Looks good to me.

If it's doable, could we have a test please? 🙂

[Jarema]

thanks @philpennock for filling in the details.

Looks good to me, but the test would be great to have 🙂

[caspervonb]

One concern here is that match is in source order but that is not guaranteed and up to code generation as far as I know so this could lead to non-determinism.

[caspervonb]

lgtm! 🙂

[Jarema]

LGMT!