fix snapshot restore and recovery endpoint

[hogesako]

Description

Fixed snapshot restore endpoint when wait_for_completion is false.
Also fixed _recovery endpoint needed for testing when wait_for_completion is false.

Issues Resolved

None

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.

[dblock]

DCO is failing + some nits

[dblock]

Suggested change

	description: Equals `true` if the restore was accepted. Present when the request had `wait_for_completion` set to `false`
	description: Returns `true` if the restore was accepted. Present when the request had `wait_for_completion` set to `false`.

[hogesako]

Unified with existing comments.
Should the existing comments also be amended?
https://github.com/opensearch-project/opensearch-api-specification/blob/main/spec/namespaces/snapshot.yaml#L386

[dblock]

Yes, please.

[github-actions]

Changes Analysis

Commit SHA: c483acb
Comparing To SHA: 5dc65a5

API Changes

Summary

├─┬Paths
│ ├─┬/_snapshot/{repository}/{snapshot}/_restore
│ │ └─┬POST
│ │   └─┬Responses
│ │     └─┬200
│ │       └─┬application/json
│ │         └─┬Schema
│ │           ├──[➖] required (29753:17)❌ 
│ │           └──[➕] properties (29750:15)
│ └─┬/_snapshot/{repository}/{snapshot}
│   ├─┬PUT
│   │ └─┬Responses
│   │   └─┬200
│   │     └─┬application/json
│   │       └─┬Schema
│   │         └─┬accepted
│   │           └──[🔀] description (29711:30)
│   └─┬POST
│     └─┬Responses
│       └─┬200
│         └─┬application/json
│           └─┬Schema
│             └─┬accepted
│               └──[🔀] description (29711:30)
└─┬Components
  └─┬indices.recovery:RecoveryOrigin
    ├──[➕] properties (48612:9)
    ├──[➕] properties (48614:9)
    ├──[➕] properties (48616:9)
    └──[➕] properties (48620:9)

Document Element	Total Changes	Breaking Changes
paths	4	1
components	4	0

• ❌ BREAKING Changes: 1 out of 8
• Modifications: 2
• Removals: 1
• Additions: 5
• Breaking Removals: 1

Report

The full API changes report is available at: https://github.com/opensearch-project/opensearch-api-specification/actions/runs/11366888933/artifacts/2063666302

API Coverage

	Before	After	Δ
Covered (%)	588 (57.59 %)	588 (57.59 %)	0 (0 %)
Uncovered (%)	433 (42.41 %)	433 (42.41 %)	0 (0 %)
Unknown	29	29	0

[github-actions]

Spec Test Coverage Analysis

Total	Tested
504	317 (62.9 %)

[dblock]

Some more small stuff, LMK when it's ready! Thanks!

[hogesako]

@dblock
Thank you for your review.
I think the work is complete.
If there is any work that needs to be done, please let me know.

[dblock]

Sorry one more nit. It should say "Returns" in the description and let's split the test file.

Thanks for opening opensearch-project/OpenSearch#16334.

[dblock]

Suggested change

	description: Return `true` if the snapshot was accepted. Present when the request had `wait_for_completion` set to `false`.
	description: Returns `true` if the snapshot was accepted. Present when the request had `wait_for_completion` set to `false`.

[dblock]

Suggested change

	description: Return `true` if the restore was accepted. Present when the request had `wait_for_completion` set to `false`.
	description: Returns `true` if the restore was accepted. Present when the request had `wait_for_completion` set to `false`.

[dblock]

This should live in its own file, so restore.yaml and recovery.yaml where the snapshot would be a prologue. This way you don't need multiple-paths-detected warning suppression and the sample can be used in a separate documentation page for _recovery.

[hogesako]

The following error occurs when a snapshot is deleted in the epilogue immediately after an asynchronous restore.

ERROR   EPILOGUES
        ERROR   DELETE /_snapshot/{repository}/{snapshot} ([my-fs-repository:my-test-snapshot/KIVGLRXyR168qOKeAS1sIw] cannot delete snapshot during a restore in progress in [RestoreInProgress[{9gz8AVvDRPm9e2ZU8Gdw9A}{my-fs-repository:my-test-snapshot/KIVGLRXyR168qOKeAS1sIw}]])

Therefore, I placed the test for the _recovery endpoint in the chapters to wait for the restore to complete(response cannot be specified in epilogue).
I would be grateful if you could let me know if there is a better method.

[dblock]

We can leave it like this for now, no big deal.

[dblock]

Could you please open an issue describing this? I think epilogues should be able to deal with the response, too.