[Feature Request] Support disabling host verification

[burnhamd]

Is your feature request related to a problem? Please describe.

Related to the python client issue temporalio/sdk-python#463
The current client implementation requires a CA cert verification. However in the case of internal communication where encryption in transit is required, but it is impractical to implement a CA for a local cluster this makes us jump through hoops to attempt to get things working.

Describe the solution you'd like

A desired implementation would be that if the CA cert and domain are not entered in the TLSConfig that the CA cert is not verified and TLS is still used. Could implement a warning message to let people know this is happening or optionally add another option that removes this warning or enables this behavior.

[cretz]

Thanks for the issue! We will look into whether this is even possible with our Rust-based gRPC client (it may not be at first glance at https://docs.rs/tonic/0.12.3/tonic/transport/channel/struct.ClientTlsConfig.html) and prioritize accordingly.

[Sushisource]

So this isn't currently possible (without some major hoop jumping - IE: using a custom TLS transport rather than one of Tonic's built in ones) in Tonic.

If we did enable this, I would definitely require you to explicitly opt in with a flag rather than flipping it off be default if not provided.

But, regardless, I understand why this isn't easy to do in Tonic (or most Rust TLS libs for that matter) - disabling these things is paramount to not bothering at all. If you disable both cert & domain verification, then anyone can just come along with a freshly minted cert and MITM you. So, in such cases it's worth wondering what value the encryption in transit is really providing.

All that said, I do understand that sometimes you just have to check boxes. So, with that in mind I'd be happy to accept a PR here but we may not get to it ourselves in the near future. The closest example to what it'd take is linked here, but it would also have to be made to work with all our other TLS options Core exposes.