[rule based autotagging] Add Get Rule API Logic

[ruai0511]

Description

This PR introduces the get Rule API Logic.

An example API request is:

curl -XGET "localhost:9200/_wlm/rule" // get all rules
curl -XGET "localhost:9200/_wlm/rule/{_id}" // get single rule by id
curl -XGET "localhost:9200/_wlm/rule?index_pattern=a,b" // get all rules containing index_pattern as a or b 

And the return would be

{
   "rules":[
      {
         "_id":"LN1z8pQBW57iKqfUCG6A",
         "index_pattern":[
            "logs*",
            "events*"
         ],
         "query_group":"dev_query_group_id_2",
         "updated_at":"2025-02-11T00:40:12.671Z"
      },
      ...
   ]
}

Rule Schema PR:
#17238
RFC:
#16797

Check List

• Functionality includes testing.
• API changes companion pull request created, if applicable.
• Public documentation issue/PR created, if applicable.

[github-actions]

❌ Gradle check result for db57bcb: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❌ Gradle check result for f7bea2e: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❌ Gradle check result for 4d2d843: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[kaushalmahi12]

I think we should not be extending this class from ClusterManagerNodeRequest since this operation will be carried out on a data node.

[kaushalmahi12]

Can we add more details about the request and response behavior in the details of the PR ? For example what will be the structure of query payload and all. Can we confirm how other system indices support this behavior to keep the behavior uniform.

[ruai0511]

System Indices like .opensearch_*, .monitoring, .tasks, .security, .ml, etc., generally support query parameters like filters, pagination (search_after), and sorting. But those are from endpoint that supports search operations (e.g., _search, _count, etc.), and will automatically handle those parameters. For us it's a bit different because we're implementing our own get api. At this point i think supporting search_after and size should be enough

[kaushalmahi12]

Can we add a sample response in the class level comment ?

[kaushalmahi12]

we should pass these filters to the request itself so that the filtering happens at the lucene layer and we get more accurate results back rather than all the Rules from the index ?

[kaushalmahi12]

This query should contain all the filters and query clauses, that will help us remove majority of the logic in this class

[ruai0511]

Yes I modified the logic

[kaushalmahi12]

I think we should rename this to either .rules or .rule_index

[ruai0511]

Renamed to .rules because i think including the word 'index' in index name seems a bit redundant