The pulsar-admin doesn't set SNI properly when tlsEnableHostnameVerification is false

[fantapsody]

Describe the bug
The async-http-client used in pulsar-admin doesn't set SNI properly when tlsEnableHostnameVerification is false, see https://github.com/AsyncHttpClient/async-http-client/blob/master/client/src/main/java/org/asynchttpclient/netty/ssl/DefaultSslEngineFactory.java#L65. This will fail https requests that rely on SNI routing, like a pulsar cluster deployed behind an istio gateway.

The behavior was introduced in the PR #15824 since the async-http-client doesn't split the flag for SNI header and hostname verification. @michaeljmarshall

To Reproduce

Set tlsEnableHostnameVerification to false in the client.conf, and use pulsar-admin to operate a pulsar cluster behind the istio gateway.

Expected behavior

The pulsar-admin should set the SNI header properly.

Screenshots
N/A

Desktop (please complete the following information):

• OS: MAC OS X

Additional context

[michaeljmarshall]

@fantapsody - can you please provide the stack trace for the error you're seeing?

[fantapsody]

@michaeljmarshall The admin command doesn't give too much useful information:

./bin/pulsar-admin --admin-url https://$HOST --auth-params $TOKEN --auth-plugin org.apache.pulsar.client.impl.auth.AuthenticationToken tenants list
null

Reason: java.util.concurrent.CompletionException: org.apache.pulsar.client.admin.internal.http.AsyncHttpConnector$RetryException: Could not complete the operation. Number of retries has been exhausted. Failed reason: https://xxx:443

[github-actions]

The issue had no activity for 30 days, mark with Stale label.