chore(spanner): unflake unit tests

[sakthivelmanii]

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes #<issue_number_goes_here> ☕️

If you write sample code, please follow the samples format.

[olavloite]

Thanks, this looks promising! I have one question regarding whether this is actually a synchronization problem (so needing a lock), or just a caching problem (meaning; making it volatile should be enough).

[olavloite]

Do we really need the lock in this method? As in: Is it really possible that two threads try to call this method simultaneously? Or is the problem just that there are two threads calling this method quickly after each other, and one of them does not (always) see the result of the previous call by another thread? And would in the latter case just making stream volatile be enough?

The reason for asking is mainly because:

1. If it is so that multiple threads can call this method simultaneously, from where does that happen? (If it is guaranteed that it does not happen in parallel, then the rest of this can be ignored)
2. If that happens from both computeNext() and initiateStreaming(), then a potential follow-on problem could be that the call from computeNext() is executed first, and that will then not set a value for streamMessageListener.
3. And otherwise; If both parallel calls come through initiateStreaming(); Could we instead synchronize those calls? Or somehow prevent that from happening in parallel?

[sakthivelmanii]

volatile didn't actually fix the issue. Let me try to figure out the issue at the root.

[sakthivelmanii]

Issue:

1. We are trying to request for initial chunks in startStream which returns the stream.
2. We are trying to request chunks before stream object returned to startGrpcStreaming in ResumableStreamIterator
3. Because of this, chunk is received first and it created ProduceRowsRunnable thread and internally it called GrpcResultSet#next() and that internally ResumableStreamIterator#computeNext() which creates the stream if it's null
4. Due to this reason, 2 begin transaction were started which is causing the the test failure.

@olavloite I have shared the events with you in chat which confirms this behaviour.