Use the REQ priority for incoming connection tasks by the acceptor

When accepting new incoming connections in the acceptor thread, it would
schedule, they would be registered with the VCA priority. This priority is
reserved for the acceptor thread itself, and specifically is not included
in the TASK_QUEUE_CLIENT categorisation. This would interfere with the
thread reserve pools.

t02011.vtc had to be adjusted to account for the new priority
categorisation of the initial request.

bin/varnishd/cache/cache_acceptor.c

@@ -516,7 +516,7 @@ vca_accept_task(struct worker *wrk, void *arg)
 
 		wa.acceptsock = i;
 
-		if (!Pool_Task_Arg(wrk, TASK_QUEUE_VCA,
+		if (!Pool_Task_Arg(wrk, TASK_QUEUE_REQ,
 		    vca_make_session, &wa, sizeof wa)) {
 			/*
 			 * We couldn't get another thread, so we will handle

bin/varnishtest/tests/t02011.vtc

@@ -20,8 +20,8 @@ server s1 {
 # at this point, so when we try to get a second stream, we fail.
 
 varnish v1 -cliok "param.set thread_pools 1"
-varnish v1 -cliok "param.set thread_pool_min 5"
-varnish v1 -cliok "param.set thread_pool_max 5"
+varnish v1 -cliok "param.set thread_pool_min 6"
+varnish v1 -cliok "param.set thread_pool_max 6"
 varnish v1 -cliok "param.set thread_queue_limit 0"
 varnish v1 -cliok "param.set thread_stats_rate 1"
 varnish v1 -cliok "param.set feature +http2"
@@ -66,10 +66,10 @@ client c1 {
 } -run
 
 # trigger an update of the stats
-varnish v1 -cliok "param.set thread_pool_max 6"
-varnish v1 -cliok "param.set thread_pool_min 6"
+varnish v1 -cliok "param.set thread_pool_max 7"
+varnish v1 -cliok "param.set thread_pool_min 7"
 delay 1
-varnish v1 -cliok "param.set thread_pool_min 5"
+varnish v1 -cliok "param.set thread_pool_min 6"
 delay 1
 varnish v1 -vsl_catchup
 varnish v1 -expect sess_dropped == 0