[Remote Store][META] Request Level Durability for for remote-backed indexes (Experimental Release Tracking for 2.5)

[ashking94]

Is your feature request related to a problem? Please describe.
Add request level durability for remote-backed indices behind experimental feature flag.

Design Proposal - #2700
Feature Proposal - #1968

Request level durability assures users -

• To restore red clusters or indexes
• To recover all data up to the last acknowledged write regardless of replica count if index.translog.durability is set to request

On high level, the following changes have been made -

• Remote translog upload & download
  • [Design Proposal] Add Remote Translog for Improved Durability #5476
• Primary term validation when remote translog is enabled
  • [Remote Store] Primary term validation with replicas - New approach POC #5033
  • [Meta] NoOp replication for remote translogs with NRT segment replication #4507
• Peer Recovery changed when remote translog is enabled
  • [Remote Store] Change of behaviour in replica recovery for remote translog enabled indices #4527
• Refresh level durability
  • [Remote Store] Support refresh level durability #5251
• Failover Integration of Segment/Translog from remote store
  • [Remote Store] Integrate translog download in failover (replica-primary promotion) #5637
  • [Remote Store] During failover, download segments from remote segment store for a lagging replica #4578

Items tracked for 2.5 release -

• [Remote Store] Integration of remote translog and remote segment store #3754
• [Remote Segment Store] Failure handling #3906
• [Remote Store] During failover, download segments from remote segment store for a lagging replica #4578
• [BUG] BufferedChecksumStreamInput.read() throws EOFException instead of returning -1 #4820
• [Remote Store] Support refresh level durability #5251
• [Remote store] Replication handling for remote translog for primary & replicas #3786
• [Discuss] Writes on NRT Replica with Remote Translog  #3706
• [Remote Store] With no-op replication, remove the payload to the in-sync calls to replicas #4229
• [Remote Store] Skip translog replay in Recovery code for the replica's recovery when translogs stored remotely.  #4230
• [Remote Store] Remove acquire PRRL during replica recovery if remote translog is enabled  #4502
• [Remote Store] Introduce replication tracker proxy layer to make checkpoint related methods as no-op  #4503
• [Remote Store] Remove reliance of checkpoints from primary shard if remote translog is enabled #4504
• [Remote Store] Remove reliance of checkpoints from replica shards if remote translog is enabled #4505
• [Remote Store] Redefine the insync allocations if remote translog is enabled #4506
• [Remote Store] Change of behaviour in replica recovery for remote translog enabled indices #4527
• [Remote Store] Primary term validation with replicas - New approach POC #5033
• [Remote Store] Primary term validation in TransportShardBulkAction on replicas when remote translog is enabled #5464
• [Remote Store] Integrate translog download in failover (replica-primary promotion) #5637
• [Design Proposal] Add Remote Translog for Improved Durability #5476
• [Remote Translog] Introduce Remote Translog with upload functionality  #5477
• [Remote Translog] Implement download functionality  #5566
• [Remote Translog] Remote Translog Truncation and Deletions  #5567

High level sub-METAs -

• [Meta] NoOp replication for remote translogs with NRT segment replication #4507

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[saratvemulapalli]

@ashking94 this is labelled 2.5, code freeze is 1/10 do you think you can make it?

[ashking94]

@saratvemulapalli We are on track. There are currently 2 open issues all of which are in flight and corresponding PRs would get merged before the code freeze. Also, this is the meta for remote store 2.5 release which we are tracking in the opensearch projects dashboard here.

[kotwanikunal]

@saratvemulapalli We are on track. There are currently 2 open issues all of which are in flight and corresponding PRs would get merged before the code freeze. Also, this is the meta for remote store 2.5 release which we are tracking in the opensearch projects dashboard here.

@ashking94 Please update or resolve the issue as all of the sub issues are marked complete.