[META] Migrate Anomaly Detector plugin to work as an Extension

[owaiskazi19]

Is your feature request related to a problem?

To make sure AD works as an extension, all the required extension points for creating a detector should be covered.

1. Build AD, JS plugin with 3.0.0-SNAPSHOT and publish it to maven local. It can be consume later by the SDK. - [Feature/extensions] Build AD with OpenSearch 3.0  anomaly-detection#645
2. Remove the dependency of JS in AD plugin. - [FEATURE] Remove Job Scheduler code from AD Extension #113
3. Remove the dependency of Common Utils in AD plugin - [FEATURE] Remove Common Utils code from AD Extension  #117
4. Integrate the local published SDK with AD build.gradle - [FEATURE] Integrate the local published SDK with AD  #133
5. Create a main class to use the imported code available from SDK - [FEATURE] Integrate the local published SDK with AD  #133
6. Replacement of opensearchplugin for Extensions -[FEATURE] Replacement of opensearchplugin for Extensions #137

[saratvemulapalli]

@owaiskazi19 I've assigned it to you as you've already done some work and wanted to pick up.
In the meanwhile, I'll pick up: #80

[owaiskazi19]

For integrating SDK with AD plugin's issue. There are 2 approaches we can look for

1. Publish artifacts to Maven and use SDK as a library. This will help us to just import the code from SDK rather than having the whole SDK package in AD extension. Issue for the same [FEATURE] Publish Artifacts to Maven Local #98
2. Integrate SDK repo with AD extension's feature/extenions branch

The 1st helps us to integrate SDK in a more generalized way.

[dbwiddis]

There are 2 approaches we can look for

1. Publish artifacts to Maven and use SDK as a library. This will help us to just import the code from SDK rather than having the whole SDK package in AD extension.

Strongly in favor of this. SDK will be consumed by multiple extensions so having it in a library will help us keep the "common" SDK code separated from extension-specific applications and force us to keep the concepts separate.

I think we're already moving in the direction of doing this for "Maven Local" but as the API becomes more stable and we are ready to collect more community input we will want to publish SNAPSHOTs.

2. Integrate SDK repo with AD extension's feature/extenions branch

Not a good primary plan. Everything will eventually need to move to a separate library so there is no reason to intentionally put things in one location.

Granted, I expect that some things we write for AD, we will later find we are duplicating the code in another extension and we might find a way to combine them into an Abstract SDK class both extensions can inherit from, but this should be the exception rather than the rule.

[owaiskazi19]

Strongly in favor of this. SDK will be consumed by multiple extensions so having it in a library will help us keep the "common" SDK code separated from extension-specific applications and force us to keep the concepts separate.

Thanks @dbwiddis for your input on this. We are moving forward with the 1st approach.