Refactor SdkClient to a concrete class with delegate implementation

[dbwiddis]

Description

Refactors SdkClient interface to a concrete class containing a delegate implementation. This allows it to be injected in the createComponents() extension point and available to @Inject constructors.

Uses Cluster Settings to determine which implementation is generated by the SdkClientFactory.

Adds SSL/TLS and Basic Auth to the remote client.

Adds an AWS OpenSearch Service client.

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[dhrubo-os]

I assume we can use sdkClient like this way for testing in algorithms module as we can't import SDKClientFactory class to algorithm module?

[dbwiddis]

Yes but you'd still need the LocalClusterIndicesClient. One possibility is moving that default client to the common module since it doesn't need the Jackson stuff that the DDB Client does.

[dhrubo-os]

That could be a easy workaround. Do you want to address that in this PR? Or in another PR?

[dbwiddis]

Probably another PR. I may make another attempt to solve the jackson problems.

[dhrubo-os]

Cool, so that means we don't need to do ?

ModulesBuilder modules = new ModulesBuilder();
modules.add(new SdkClientModule(client, xContentRegistry));

 injector = modules.createInjector();

 // Get the injected SdkClient instance from the injector
 SdkClient sdkClient = injector.getInstance(SdkClient.class);

[dbwiddis]

Correct. That created an injector that was different than the one OpenSearch processes with the list of objects from createComponents(). But the clients still had their runtime class so those would still have been bound to the subclasses, and this really just made a new/different SdkClient available to the various other classes in this method. We could have just instantiated an sdkClient without jumping through these hoops and gotten the same thing.

With the new code we have a concrete class SdkClient that is injected and available by its class key (which is what the separate module was doing) and hides the implementation as an internal field. Not the most object-oriented way to do things, but it works around the injection headaches.

[dhrubo-os]

I assume these settings will eventually move to core, right?

Otherwise we usually keep our settings in one place:

ml-commons/plugin/src/main/java/org/opensearch/ml/settings/MLCommonsSettings.java

Line 17 in 0b9708b

public final class MLCommonsSettings {

[dbwiddis]

Yes, these are intended to be moved to wherever this whole package will eventually move (an OpenSearch module? Another plugin? The SDK for Java extensions repo? But it will not remain in ML Commons long term and those settings names will probably change when we relocate it.