[PROPOSAL] Improve usability of ApacheHttpClient5TransportBuilder

What/Why

What are you proposing?

Reduce the amount of code one needs to write to connect to OpenSearch with ApacheHttpClient5TransportBuilder.

Instead of

val host = org.apache.hc.core5.http.HttpHost.create(endpoint)
                transport = ApacheHttpClient5TransportBuilder.builder(host)
                        .setMapper(JacksonJsonpMapper())
                        .setHttpClientConfigCallback({ httpClientBuilder ->

                            // BASIC auth, username/password
                            val username: String? = System.getenv().getOrDefault("USERNAME", null)
                            val password: String? = System.getenv().getOrDefault("PASSWORD", null)
                            if (username != null && password != null) {
                                val credentialsProvider = BasicCredentialsProvider();
                                credentialsProvider.setCredentials(
                                    AuthScope(host),
                                    UsernamePasswordCredentials(username, password.toCharArray()));
                                httpClientBuilder.setDefaultCredentialsProvider(credentialsProvider)
                            }

                            // localhost, disable TLS
                            if (endpoint.startsWith("https://localhost:")) {
                                val sslContext = SSLContextBuilder
                                    .create()
                                    .loadTrustMaterial(null, {_, _ -> true })
                                    .build();
                                val tlsStrategy = ClientTlsStrategyBuilder.create()
                                    .setSslContext(sslContext)
                                    .setHostnameVerifier(NoopHostnameVerifier.INSTANCE)
                                    .build();
                                val connectionManager = PoolingAsyncClientConnectionManagerBuilder.create()
                                    .setTlsStrategy(tlsStrategy)
                                    .build();
                                httpClientBuilder.setConnectionManager(connectionManager);
                            }

                            httpClientBuilder
                        })
                        .build()

                transport = ApacheHttpClient5TransportBuilder.builder(endpoint)
                    .withBasicAuth(username, password)
                    .verifySSLHosts(false)
                    .build()

The two changes above are a helper for BASIC auth and a simply way to disable SSL verification, which are common things people do for local testing. Finally, all builders could take a String endpoints (URLs).

What users have asked for this feature?

I wrote a [Kotlin sample](https://github.com/dblock/opensearch-kotlin-client-demo] that attempts to connect to either a local (docker) instance of OpenSearch or Amazon OpenSearch. This requires using two different transports and causes at least one imported namespace to conflict, making code cumbersome.

The sample in https://github.com/opensearch-project/opensearch-java/blob/main/samples/src/main/java/org/opensearch/client/samples/SampleClient.java is similarly annoying to write.

What problems are you trying to solve?

Simplify writing code that works in common scenarios and in connecting to either a self-hosted OpenSearch and/or AWS.

What is the developer experience going to be?

Less code.

Are there any security considerations?

Making it very easy to disable TLS or add basic auth may lead to unexpected side effects.

Are there any breaking changes to the API

No.

Start with ApacheHttpClient5TransportBuilder and compare its current usage with samples/src/main/java/org/opensearch/client/samples/SampleClient.java and the linked Kotlin sample. Define a compatible API for String endpoints, basic authentication, and optional SSL verification, then verify that common local and AWS connection scenarios require less code without introducing the stated security or breaking-change concerns.