Refactor IndexManagement to support custom actions

[downsrob]

Index State Management Refactor

This PR makes Index Management extensible and refactors the existing IndexStateManagement (ISM) actions to be built using the new extensible interface. This interface enables you to create extension plugins which can be loaded by index management. Your extension plugin can provide two things:

1. New ISM actions
2. New index types with custom index metadata services. For example, if you offload your hot data to a persistent storage system, the "cold" index's IndexMetadata is not in cluster state, where hot index metadata is, so you need to provide a custom metadata service for ISM to manage it.

Goals

• Define a new interface in IndexManagement SPI (SPI interface is provided by OpenSearch framework to extend a plugin) to allow the creation of custom actions in new plugins which extend the Index Management SPI.
• Refactor all ISM actions in IndexManagement based on the new SPI
• Refactor the ManagedIndexCoordinator, ManagedIndexRunner and ISM Rest APIs to use the new interface methods to process requests for different index types
• Enable the creation of custom index types and metadata services, decoupling metadata from the cluster state and allowing an extension to manage off cluster indices.

Key Interfaces

• IndexManagementExtension - The interface for plugins extending index management. Through this interface, you define the extension name, and the custom action parsers. Optionally, you may provide a map of custom index type to metadata service, enabling an extension to provide a custom method of getting ISMIndexMetadata, which contains index uuid and index creation date. This uuid is used to uniquely identify an index, so that a policy may be attached to it. The index creation date is used for transitions. By decoupling uuid and index creation date from the cluster state, an extension can enable ISM to manage off cluster indices. This interface also allows for a custom StatusChecker, used to denote whether the extension is enabled or disabled.
• Action - The interface for custom actions. By extending this interface, you may create a custom action with new fields, and add the implementation to correctly serialize the internals of the action when stored internally or returned as response. Actions are further split into Steps where each Action can be executed in multiple steps.
• ActionParser - The interface for the parsing of custom actions. A custom parser is needed for each custom action, and it provides implementation for the deserialization of the internals of actions. It is also important to note the action type in this interface. This action type must be unique, it typically describes what the action does, such as "rollover" for the rollover action.
• Step - Provides the implementation of the action execution, as well as fields such as if the step may be safely disabled on, if it is idempotent, and the step name.

Example

Though we do not yet provide an example plugin, a sample parser, action and step are implemented here. This custom action is used for unit testing, and does not actually execute anything meaningful. As Index management internal actions also follow these interfaces, you can refer to the internal actions for more examples. Example step with meaningful execution: attempt_close

Additional Information

This commit squashes all refactoring changes, for a more granular view of the changes you can check out the commit history of the development branch.

CheckList:

• 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.