vtc: Another c69 and c93 stabilization attempt

Even thought the first rxresp implies that the backend fetch must have
completed, it is still possible to observe a streaming hit.

Since resp.is_streaming merely looks at the presence of a boc, and not
whether its state is lower than FINISHED, waiting until we see the fetch
end in the logs and forcing a new client session should reduce the race
window in those test cases.

We could also try to settle on the value of resp.is_streaming when we
hit an object in the cache or resume from a backend fetch and change the
semantic to whether resp was streaming when VCL entered the subroutine.

By that I mean, with a proper check of the boc state.

bin/varnishtest/tests/c00069.vtc

@@ -33,18 +33,24 @@ varnish v1 -vcl+backend {
 	}
 } -start
 
+logexpect l1 -v v1 -q "Begin ~ bereq" -i End {
+	expect 0 1002 End
+} -start
+
 client c1 {
 	txreq
 	rxresp
-	expect resp.http.streaming == "true"
+	expect resp.http.streaming == true
+} -run
 
-	delay 0.1
+logexpect l1 -wait
 
+client c2 {
 	txreq
 	rxresp
-	expect resp.http.streaming == "false"
+	expect resp.http.streaming == false
 
 	txreq -url /synth
 	rxresp
-	expect resp.http.streaming == "false"
+	expect resp.http.streaming == false
 } -run

bin/varnishtest/tests/c00093.vtc

@@ -27,14 +27,20 @@ varnish v1 -vcl+backend {
 	}
 } -start
 
+logexpect l1 -v v1 -q "Begin ~ bereq" -i End {
+	expect 0 1002 End
+} -start
+
 client c1 {
 	txreq
 	rxresp
-	expect resp.http.streaming == "true"
+	expect resp.http.streaming == true
+} -run
 
-	delay 0.1
+logexpect l1 -wait
 
+client c2 {
 	txreq
 	rxresp
-	expect resp.http.streaming == "false"
+	expect resp.http.streaming == false
 } -run