Modified _stop replication API to remove any stale replication settings on existing index

[saikaranam-amazon]

Signed-off-by: Sai Kumar karanas@amazon.com

Description

Modified _stop replication API to remove any stale replication settings on existing index

• This is useful to remove the any carried over settings on the leader cluster due to restore.

Issues Resolved

#342

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• 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.

[codecov-commenter]

Codecov Report

Merging #410 (c0f1bc0) into main (043d860) will decrease coverage by 0.93%.
The diff coverage is 78.26%.

❗ Current head c0f1bc0 differs from pull request most recent head 69585b6. Consider uploading reports for the commit 69585b6 to get more accurate results

@@             Coverage Diff              @@
##               main     #410      +/-   ##
============================================
- Coverage     73.97%   73.03%   -0.94%     
+ Complexity      995      981      -14     
============================================
  Files           141      141              
  Lines          4554     4566      +12     
  Branches        504      507       +3     
============================================
- Hits           3369     3335      -34     
- Misses          862      917      +55     
+ Partials        323      314       -9     

Impacted Files	Coverage Δ
...action/stop/TransportStopIndexReplicationAction.kt	60.75% <50.00%> (-8.58%)	⬇️
...rch/replication/task/index/IndexReplicationTask.kt	67.82% <50.00%> (-3.18%)	⬇️
...tion/action/index/TransportReplicateIndexAction.kt	74.07% <100.00%> (ø)
...tion/action/replay/TransportReplayChangesAction.kt	82.75% <100.00%> (+0.20%)	⬆️
.../org/opensearch/replication/util/ValidationUtil.kt	55.81% <100.00%> (+7.16%)	⬆️
...arch/replication/metadata/UpdateMetadataRequest.kt	77.27% <0.00%> (-22.73%)	⬇️
...ch/replication/task/index/IndexReplicationState.kt	51.66% <0.00%> (-15.00%)	⬇️
...ication/action/setup/TransportSetupChecksAction.kt	59.52% <0.00%> (-14.29%)	⬇️
...ication/seqno/RemoteClusterRetentionLeaseHelper.kt	80.00% <0.00%> (-11.67%)	⬇️
...tion/repository/RemoteClusterMultiChunkTransfer.kt	90.24% <0.00%> (-9.76%)	⬇️
... and 21 more

---

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 043d860...69585b6. Read the comment docs.

[saikaranam-amazon]

Security tests are failing as the main is tracking OS 2.0

[ankitkala]

What if the snapshot was taken while the index was getting replicated? We'd still end up having these replication specific settings on the restored index right?

[saikaranam-amazon]

What if the snapshot was taken while the index was getting replicated? We'd still end up having these replication specific settings on the restored index right?

Yes, the index can still have the settings but normally, flow to restore would be
1/ Take the snapshot from the current leader cluster (which will not be replicating) and restore on another cluster as this index will have latest changes.
2/ For the other cases, this will ensure to free the index for replication.

[krishna-ggk]

LGTM, few comments.