vtcombo: Fix race condition in StreamExecute.

[enisoc]

@alainjobart @sougou

While porting tests from java_vtgate_test_helper to vtcombo, I found
that streaming queries that fetched more than ~300 rows would indicate
success, but receive fewer rows than expected. The number of rows actually
returned was always in the same ballpark, but would fluctuate from run
to run.

It turned out that since vtcombo returns results in-memory from vttablet
to vtgate, we were returning a *Result once the rows filled up the
buffer size, and then concurrently modifying the already-returned struct
to fill in the next set of rows.

[alainjobart]

LGTM great find!

[sougou]

lgtm for now.
I think Result should be a read-only data structure. Previously, it was not enforceable because it had to have public members (for encoding). But now, sqltypes.Result could enforce it.
OTOH, we're also switching to use querypb.QueryResult, which will again make it unenforceable in those places.
But I still think we'll get better mileage if the structs were read-only.

[enisoc]

For Result to have true immutable semantics, you'd have to incur an extra copy of all row data upon sending to the callback:

https://github.com/youtube/vitess/blob/master/go/vt/dbconnpool/connection.go#L89

[sougou]

Right. We may not want to get that far. I was looking at trade-offs that will let us avoid common pitfalls without compromising performance.