Connection to TLS enabled PD failing

Hi, I have raised this issue in the tikv-wg slack. While running the client we are running into issues where the client fails to connect to a TLS enabled PD endpoint with the error:

[WARN] [config_logging.go:287] ["rejected connection"] [remote-addr="[addr]:port"] [server-name=] [error="tls: first record does not look like a TLS handshake"]

Digging into the code, the problem seems to stem from the following logic in the client (

client-rust/src/common/security.rs

Line 80 in c6110dd

let addr = "http://".to_string() + &SCHEME_REG.replace(addr, "");

)

let addr = "http://".to_string() + &SCHEME_REG.replace(addr, "");

info!("connect to rpc server at endpoint: {:?}", addr);

let mut builder = Channel::from_shared(addr)?
    .tcp_keepalive(Some(Duration::from_secs(10)))
    .keep_alive_timeout(Duration::from_secs(3));

Here SCHEME_REG is the regex to find "https" in the prefix of the address (

client-rust/src/common/security.rs

Line 19 in c6110dd

lazy_static::lazy_static! {

).

lazy_static::lazy_static! {
    static ref SCHEME_REG: Regex = Regex::new(r"^\s*(https?://)").unwrap();
}

This is a problem during the ssl handshake since the server is not acknowledging the requests sent to an addressed prefixed with "http" instead of "https". Removing the logic to mutate the address fixed the issue. But I was wondering if someone can shed some light on why it was necessary to strip out "https" from the address and replace those with "http"? Wouldn't it be simpler to make this a passthrough and have the user pass their address as is? I can raise a PR with a fix if this is unintended behavior.

I think the issue was introduce in #399 here because hyper require that the endpoint must have the scheme in URI (otherwise connection will fail and raise the error hyper::Error(Connect, "invalid URL, scheme is missing").

As client-rust allow users to provide endpoint without scheme, #399 address the connection issue by add the scheme, but miss to handle the TLS scene.

And as what is said above, to address this issue, removing the logic of mutating the address may not be enough for the scene when user pass PD endpoints without scheme.

@pingyu, a bit overdue but I have attempted to fix the issue here: #459

Fixed as part of #459