Summary
For the Serverless initiative to support shard merge feature, as part of merge transaction, the supplied commit timestamp of a non-prepared transaction could be lesser than the stable timestamp. The durable timestamp supplied will comply with the condition "stable timestamp < durable timestamp".

Motivation

• Does this affect any team outside of WT?
  Yes, the 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?
  As part of the shard merge project from the Serverless initiative, shard that will be merged would like to retain the commit timestamp from the donor but could be less than the stable timestamp at the recipient. To support the reads across the shards the commit timestamp needs to be retained as that of the donor.

• If the problem does occur, what are the consequences and how severe are they?
  shard merge could fail if this feature is not supported.

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

Acceptance Criteria (Definition of Done)
(When will this ticket be considered done? What is the acceptance criteria for this ticket to be closed?)

• Testing
  Functional testing to ensure that a non-prepared transaction could commit with a commit timestamp <= stable timestamp < durable timestamp.

• 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 non-prepared transaction to allow the commit timestamp <= stable timestamp < durable timestamp.