[i2c] Missing ACQ queue entries in ChromeOS test

Reading TPM registers via I2C using the proprietary ChromeOS protocol is done by an I2C write of a single data byte (register address) followed by an I2C read of however many bytes the host wants to read from the specified register. Typically, the host on actual Chromebooks will issue an I2C stop condition between the two, (and furthermore, for historical reasons, wait for off-band signalling that data is ready).

In our testing, we want to ensure that the OT GSC can recover, even if the I2C host reads early, though. And during those tests, I see something odd.

We expect to pull the following sequence of entries from the ACQ queue: START(write), DATA, STOP/RESTART, START(read), ... , and that is what we in fact see, if the host does a STOP condition in between.

However, without the STOP condition on the bus, what we see is START(write), DATA and then nothing further, even as a logic analyzer shows that the restart was followed by an I2C address, which the OT chip is acknowledging, while stretching the clock, as software has not put any data into the TX FIFO.

Two things would be good here:
1. When the I2C device is stretching the clock, waiting for software to put data in the TX FIFO, a timeout interrupt would be nice, in case the software state machine is broken, so that the controller could be reset, freeing up the bus.
2. The RESTART and START(read) entries should be visible in the ACQ queue, even if the controller cannot release the clock of the final ACK bit on the address. Otherwise, our software has no chance of knowing that the write of one byte is complete, and was not merely the first of a multi-byte write (which would represent a TPM register write, rather than read.)