Summary
For serverless initiative to support shard merge feature, as part of merge transaction, if the supplied commit timestamp of the transaction is lesser than the oldest timestamp, then to roundup the commit timestamp to the oldest timestamp.

Motivation

• Serverless team has a dependency on this feature to complete the shard merge project.

• How likely is it that this use case or problem will occur?
  Shard merge will not try to control the oldest timestamp advancement, hence when it fetches the oldest timestamp and tries to commit the transaction it is possible that the oldest timestamp is advanced, and shard merge has no control over it, and the transaction will fail.

• If the problem does occur, what are the consequences and how severe are they?
  Without this feature, the write transaction initiated by shard merge could fail, and at present, without controlling the advancement of the oldest timestamp there is no definite way to make the write transaction successful. An alternative could be to control the oldest timestamp advancement which could cause scalability issues.

• Is this issue urgent?
  Shard merge project is dependent on this feature.

Acceptance Criteria (Definition of Done)
Non-prepared Transactions could be configured to round up the commit timestamp to the oldest timestamp.

• Testing
  Functional testing to ensure this configuration is supported.

• Documentation update
  (Does this ticket require a change in the architecture guide? If yes, please create a corresponding doc ticket.)

[Optional] Suggested Solution

To provide a transaction configuration for the non-prepared transactions to round up the supplied commit timestamp to the new oldest timestamp.