[Remote Store] Update shallow snapshot flows to support new path types and hash algorithm

[ashking94]

Is your feature request related to a problem? Please describe

With optimised prefix pattern for remote store path (as mentioned in #12567), we need to ensure that we are able to allow indexes to use the optimised remote store path type and at the same time be able to resolve the existing prefix pattern (Fixed remote store path type) during snapshots and restores.

Describe the solution you'd like

We have updated Snapshots and it's restore after introducing shallow snapshots with remote store. Due to the changes in the blob store path for different type of data, it becomes important that we keep track of the same in shallow snapshot metadata since the snapshot can be restored outside of the life of an index (meaning that the cluster manager holds no information about the index itself). I propose the solution where we will update the shallow snapshot metadata file that will keep track of the remote store type and hash algorithm so that we can reuse this information during times of 1. restore 2. clone 3. cleaning up remote store data on account of snapshot deletion when there are no more lock files present for the same.

Related component

Storage:Performance

Describe alternatives you've considered

No response

Additional context

No response

[peternied]

[Triage - attendees 1 2 3 4 5 6 7 8]
@ashking94 Thanks for creating this issue; however, it isn't being accepted due to not having enough details to know what the expected result of resolution of the problem is. Please feel free to open a new issue after addressing the reason.

[ashking94]

@peternied I will add more details and will prefer reopening the same issue. This is an increment step of the meta #12589 to achieve #12567. Let me know if you see any concern on account of reopening this issue.

[peternied]

@ashking94 I'm not familiar with the feature area and it is not more approachable to me. I'd recommend moving into slightly different mindset while creating issues in open-source projects to careful describe the problem & why its worth while to addressing and then constraints on how it is addressed. Finally to provide context, it should be considered part of the appendix - not required reading.

By coming from this perspective unfamiliar readers can onboard quickly and be better setup to review and provide feedback on the goals of the issue and related issues.