[Workload Management] Add rule schema for workload management

[ruai0511]

Description

This PR introduces the schema for Rule object used in the workload management feature

{
    "_id": "fwhbuib397u4o03=="
    "index_pattern": ["logs123", "user*"],
    "query_group": "dev_query_group_id",
    "updated_at": "01-10-2025T21:23:456Z"
}

Related issues:
RFC: #16797
#16813

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 f6a4a28: SUCCESS

[codecov]

Codecov Report

Attention: Patch coverage is 82.60870% with 24 lines in your changes missing coverage. Please review.

Project coverage is 72.44%. Comparing base (faabd10) to head (bb8d06c).
Report is 19 commits behind head on main.

Files with missing lines	Patch %	Lines
server/src/main/java/org/opensearch/wlm/Rule.java	82.60%	9 Missing and 15 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #17238      +/-   ##
============================================
+ Coverage     72.36%   72.44%   +0.07%     
- Complexity    65733    65825      +92     
============================================
  Files          5318     5319       +1     
  Lines        305674   305812     +138     
  Branches      44349    44376      +27     
============================================
+ Hits         221197   221535     +338     
+ Misses        66341    66128     -213     
- Partials      18136    18149      +13     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

❕ Gradle check result for bb8d06c: UNSTABLE

Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

[jainankitk]

Should we also have customer friendly - name/description fields for a rule?

[jainankitk]

This design of using same rules for multiple features becomes really tricky if they have different allowed attribute values. Having more attributes present than the ones that apply to a rule can be very confusing and if we are not allowing that, the possible attributes is the intersection of allowed attributes for all the features.

[jainankitk]

@ruai0511 / @kaushalmahi12 - Can we add some more examples of how these rules will look if we have multiple features and multiple attributes tomorrow? Especially when the allowed attributes for those features are not common

[kaushalmahi12]

A single Rule entity will always map to a single feature. Hence each feature will define their set of allowed attributes.

For example since the slow logs are defined at index level. It doesn't make sense for s.ow log feature to consider index_pattern as attribute. It can define next layer of attributes to provide more specific details about the slow logs,

[ruai0511]

Yeah a single rule will only have one feature but could have multiple attributes.
For example,

{
    "_id": "fwhbuib397u4o03=="
    "attribute_1": ["logs123", "user*"],
    "attribute_2": ["logs123", "user*"],
    "query_group": "dev_query_group_id",
    "updated_at": "01-10-2025T21:23:456Z"
}

Here the feature is query_group, and corresponds to the tag dev_query_group_id

[kaushalmahi12]

We should move this file under a new package e,g; auto_tagging since the construct is meant to be used in generic context but the structure hints a specific use.