Add back opendistro prefixed sweeper enabled field to alerting stats response

[qreshi]

Signed-off-by: Mohammad Qureshi [email protected]

Issue #, if available:

Description of changes:
The opendistro prefixed field response for sweeper/scheduled jobs enabled in the Alerting Stats API was inadvertently changed to plugins during the migration to OpenSearch. This change reintroduces the legacy field back alongside the existing plugins one to maintain backwards compatibility and to not break behavior for anyone using the current field.

This PR also updates the existing tests asserting on the response of the stats API to use hardcoded values for the scheduled jobs enabled field instead of referring to the Setting.key so it can catch a change like this in the future. We should also see if any other tests are currently checking API responses this way. Fixing those, however, is out of scope for this particular PR.

CheckList:
[x] 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.

[getsaurabh02]

LGTM however you may want to consider the suggestion around Rest API ITs.

[getsaurabh02]

Can we add a Resource File with the Rest API response, and assert on those values instead. You may want to check how it is achieved similarly in Rest ITs of the core. I feel it's more manageable that way and you will not have to define the explicit fields in the test here.

[qreshi]

Personally, I think way we're currently asserting here is cleaner since for some tests we just want to check specific values and not the entire response. If we had a resource file then we'd need to handcraft the entire responses for new cases that aren't covered by the old ones. That would be more appropriate for unit tests where we're mocking but would add overhead here.

[getsaurabh02]

You can also have resource file versioned since any new API changes would only happen with a change in the minor version. Also, the validation would be between the objects in resource file and the API response here, not necessarily requiring any mock. In order to check for any specific values, we can always filter the object in consideration, given it will be a json structure.

Just that having a resource file would defines one source of truth to compare the API responses against. However, it is just an open idea, and might not necessarily be included in the scope of this PR. Feel free to skip it for now.

[qreshi]

Fair point. Let's skip it for this PR but can you create an issue capturing this and we can continue discussions there and have others weigh in on the option.

[codecov-commenter]

Codecov Report

Merging #283 (0d15bf1) into main (f92dec0) will increase coverage by 0.00%.
The diff coverage is 20.00%.

@@            Coverage Diff            @@
##               main     #283   +/-   ##
=========================================
  Coverage     78.63%   78.64%           
+ Complexity      218      217    -1     
=========================================
  Files           173      173           
  Lines          6968     6971    +3     
  Branches        915      916    +1     
=========================================
+ Hits           5479     5482    +3     
+ Misses         1002     1001    -1     
- Partials        487      488    +1     

Impacted Files	Coverage Δ
...search/alerting/transport/SecureTransportAction.kt	39.02% <0.00%> (+8.25%)	⬆️
...ing/core/action/node/ScheduledJobsStatsResponse.kt	65.38% <100.00%> (+1.38%)	⬆️
...ing/destination/client/DestinationEmailClient.java	72.50% <0.00%> (-5.00%)	⬇️
...ing/model/destination/DestinationContextFactory.kt	66.66% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 813f836...0d15bf1. Read the comment docs.