What we built in PM-2210 was to allow (internal) transactions to opt into storing history for each stmtId and then return the original response if some stmtId is retried. This should work out of the box for bulkWrite as bulkWrite also accepts a vector of stmtIds as its input. If a bulkWrite is executed inside an internal transaction on behalf of a client retryable write request, each op in the bulkWrite should have the same stmtId as its corresponding original write statement. Such bulkWrite may contain additional write statements that are not explicitly requested by a client retryable write command. In that case, we should assign stmtId kUninitializedStmtId (-1) for those auxiliary ops when executing bulkWrite in the internal transaction. Like insert/update/delete, the bulkWrite command will also include an unstable retriedStmtIds field in its response used internally to support retryability when running bulkWrite inside an internal transaction.

This ticket should make sure the retriedStmtIds field is properly used and add tests for running bulkWrite in internal transactions (especially for retryability).