Fix negative requestStats memory_size issue

[sgup432]

Description

• This solves the bug where RequestStats memory_size metric was going negative in certain scenarios as reported in the issue.

Why so?

• It turns out that the issue occurs when an indexShard is deleted and then reallocated on the same node. So whenever stale entries from older shard are deleted, those are accounted for the new shard which has the same shardId.

Why did it happen now?

We made changes recently as part of 2.12 to make IndicesRequestCache key serializable. Earlier we were storing an actual reference to indexShard in the cache. But with the new change we extract indexShard from shardId which eventually caused the above issue.

Related Issues

Resolves #13343

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Failing checks are inspected and point to the corresponding known issue(s) (See: Troubleshooting Failing Builds)
• Commits are signed per the DCO using --signoff
• Commit changes are listed out in CHANGELOG.md file (See: Changelog)
• [ ] Public documentation issue/PR created

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.

[github-actions]

❌ Gradle check result for 2dee809: 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 417ca9d: 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 9f5a8cd: 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 d52ce39: 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 f35ff3a: SUCCESS

[codecov]

Codecov Report

Attention: Patch coverage is 88.46154% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 71.61%. Comparing base (b15cb0c) to head (f35ff3a).
Report is 267 commits behind head on main.

Files	Patch %	Lines
...va/org/opensearch/indices/IndicesRequestCache.java	88.88%	0 Missing and 2 partials ⚠️
...nsearch/index/cache/request/ShardRequestCache.java	87.50%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #13553      +/-   ##
============================================
+ Coverage     71.42%   71.61%   +0.19%     
- Complexity    59978    61118    +1140     
============================================
  Files          4985     5052      +67     
  Lines        282275   287137    +4862     
  Branches      40946    41604     +658     
============================================
+ Hits         201603   205631    +4028     
- Misses        63999    64564     +565     
- Partials      16673    16942     +269     

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