fix: Address assertion error in TestReadRows_Retry_LastScannedRow conformance test

[danieljbruce]

Summary:

The TestReadRows_Retry_LastScannedRow conformance test is failing because the client retries requesting more rows than it should. The code changes in this PR introduce more technical debt, but provide a solution so that the test passes.

Background:

In the conformance test, the mock server sends back three data events. The first and the third data events contain rows with ids equaling 'abar' and 'zbar' respectively while the second event contains no rows. The second event however has a lastScannedRow property set to 'qfoo'. The retry is made for rows after 'abar', but the test is expecting a retry for rows after 'qfoo' so the test fails.

Retries are now made for data after the lastRowKey which is updated in the user stream ever since the fix to the data loss issue. The second data event containing the lastScannedRow property equal to qfoo reaches the chunk transformer, but doesn't do anything to update the lastRowKey variable mentioned in the user stream. This PR is a fix to ensure the lastRowKey is updated and qfoo is not re-requested and it does this by emitting a new event from the chunk transformer.

All of the source code changes in this PR are for a streaming pipeline that services ReadRows calls. Here is the order of the streams in the pipeline for context:

server -> request stream -> chunk transformer -> toRowStream -> rowStream -> user stream

Here is why we emit an event in the chunk transformer to change the lastRowKey:
When the chunk transformer receives a data event with chunks of data then we have to ensure those chunks will make it to the user before the lastRowKey is changed based on the lastScannedRow property. For example, say the data event has data chunks where chunk 1 is [row1, row2, row3] and chunk 2 is [row4, row5, row6]. Suppose the data event also has lastScannedRowKey equal to row 8 and then receives a retryable error when only row 1 and row 2 have reached the user stream. In this case, all rows except row 1 and row 2 will be thrown away and should be re-requested in the next retry. In this example, it is important that lastRowKey is not set to row 8 yet. To ensure rows thrown away by the client always get re-requested, the chunk transformer emits an event to change the lastRowKey downstream after all rows in chunks are delivered to the user stream.

Changes:

src/chunktransformer.ts:
When the chunk transformer receives a lastScannedRow then it pushes a LAST_ROW_KEY_UPDATE event to update the lastRowKey downstream in the user stream. It does not attempt to update the lastRowKey in the chunk transformer because it is important that all data ahead of the lastScannedRow data makes it to the user stream first. Therefore, this event gets queued behind all data that has already been sent eventually to be consumed by the user stream.

src/mutation.ts:
The linter complained about this file so a single cast is added

src/tabular-api-surface.ts:

1. In the user stream, an if block is added. The code added inside the if block will be used if the chunk transformer received an event with lastScannedRow data and then emitted an event with the intent of updating the lastRowKey in the user stream.
2. The toRowStream transformer has code from before for handling rows passed in from the chunk transformer and new code for ensuring lastScannedRowKey related events are passed along from the chunk transformer to the user stream.

testproxy/known_failures.txt:
The changes address the TestReadRows_Retry_LastScannedRow test so this test is removed from the list.

Next Steps:

• Remove the technical debt from this PR by following this plan