Add Support for Additional Fields in Put Request

[MohammedAghil]

Problem

At present, the Put Request does not support fields such as sequence number and primary term which can lead the open search specific store to perform an index request without checking if the document's last modification was assigned the given sequence or primary term. This affects the concurrency mechanism for open search specific store.

Propose to add these fields similar to how it is done for Update Request

public UpdateDataObjectRequest(
        String index,
        String id,
        String tenantId,
        Long ifSeqNo,
        Long ifPrimaryTerm,
        int retryOnConflict,
        ToXContentObject dataObject
)

[dbwiddis]

Hey @MohammedAghil first off, thanks for using this client. I'm excited to see it used beyond its initial use cases.

Implementing new features of request objects isn't quite as easy as just adding the fields (as in #137 so far). The fields added need to then be passed on to the store-specific request object.

• for Local Client this is easy, it's the same IndexRequest
• for Remote Client this is also easy, the Java client has these parameters that we can include
• for Dynamo DB, it's a lot harder. DDB does not have this type of concurrency control and we have to work around it. See here for what we had to implement to track seqNo on DDB. (We ignore primary term as DDB doesn't have a primary/replica shard concept.)

It's uncommon to actually use these fields for indexing a document. Generally to get these values to begin with, you already did a "get" and if it doesn't exist, you would only use the "unassigned" values.

There are essentially 3 use cases here:

• Index a new document
  • they aren't used, or if they are used they would have to be the "unassigned" values, and you can use the overwriteIfExists boolean instead
• Update an existing document by field
  • this doesn't apply to indexing in any way
• Update an entire existing document
  • this seems to be the use case supported but in this case, an update request would work.

So one option here is for the calling code to implement a conditional "If seqNo and primary term != unassigned values" then update, otherwise index.

I know it's preferable to migrate as close as possible to existing code, so I'm not opposed to adding these. Note that the entire reason they exist is that all the mutating actions (index/update/delete) extend TransportSingleItemBulkWriteAction. So if you want to add to Put (Index) let's also add to Delete. And fully combine the implementations in the DDB Client (there's probably room to refactor some the SeqNo handling parts to reduce repetition.)