Clear vary prediction marker (vary_l) on restarts

In dea05fa4, an assertion was added
that, if a vary prediction exists as marked by vary_l, that marker
matches the actual length.

This change uncovered an inconsistency where, for waitinglist returns,
the predictive vary was cleared unconditionally (req->vary_b[2] = '\0'
in VRY_Prep()), but vary_l was not.

Consequently, before dea05fa4,
VRY_Finish() would copy more of the (possibly empty) vary spec
than necessary.

This commit fixes the inconsistency and adds specific testing
for the case.

Fixes #3858

bin/varnishd/cache/cache_vary.c

@@ -237,6 +237,7 @@ VRY_Prep(struct req *req)
 	req->vary_e = req->vary_b + WS_ReservationSize(req->ws);
 	if (req->vary_b + 2 < req->vary_e)
 		req->vary_b[2] = '\0';
+	req->vary_l = NULL;
 }
 
 void

bin/varnishtest/tests/c00004.vtc

 varnishtest "Test Vary functionality"
 
+barrier b1 cond 3
+
 server s1 {
 	rxreq
 	expect req.http.foobar == "1"
@@ -20,6 +22,17 @@ server s1 {
 	rxreq
 	expect req.http.foobar == ""
 	txresp -hdr "Vary: Foobar" -hdr "Snafu: 5" -body "5555\n"
+
+	# #3858 test vary prediction turning out wrong
+	# no Vary, HFM and waitinglist
+	rxreq
+	expect req.http.foobar == "x"
+	barrier b1 sync
+	txresp -hdr "Cache-Control: no-cache"
+
+	rxreq
+	expect req.http.foobar == "x"
+	txresp -hdr "Cache-Control: no-cache"
 } -start
 
 varnish v1 -vcl+backend {} -start
@@ -67,5 +80,24 @@ client c1 {
 	expect resp.status == 200
 	expect resp.http.X-Varnish == "1011"
 	expect resp.http.snafu == "5"
-
 } -run
+
+client c1 {
+	txreq -hdr "Foobar: x"
+	barrier b1 sync
+	rxresp
+	expect resp.status == 200
+	expect resp.http.Vary == <undef>
+} -start
+
+client c2 {
+	txreq -hdr "Foobar: x"
+	barrier b1 sync
+	rxresp
+	expect resp.status == 200
+	expect resp.http.Vary == <undef>
+} -start
+
+
+client c1 -wait
+client c2 -wait