Fix yb_dml_read_time regression test

[jfunston]

This test reads and writes the same table in a single statement. The read is executed as a single, potentially paginated, K2 query. The writes are interleaved with the reads, one row is written after consuming one row from the read. If the query is paginated we run into a bug where the writes from the same statement are read by subsequent paginated requests, which means that too many records are get written. Yugabyte solves this by setting a read_time at the SQL op level, so their read sees a consistent view as new data is inserted.

A potential solution for us is to maintain versioned write intents from the same transaction on the server. These write intents would be versioned by the sequence id from the client (currently used to detect retried operations), while non write intent records are still versioned by timestamp as usual. A read would use the sequence id to only observe previous writes within the transaction. This is less powerful than the Yugabyte approach because we would not let the user set the sequence id of reads so we need to convince ourselves that it is sufficient to work in all SQL use cases.