Bug#11766349 - 59443: query_cache_debug.test is occasionally very slow

The test case problem stemmed from the fact that a debug sync
signal is a global variable that persists until overwritten
by a new signal. This means that if two different signals
are raised in sequence, a thread waiting for the first signal
might miss it if the second signal sets the global variable
before the thread wakes up.

The solution is to deliver a subsequent signal only after the
waiting thread has received it.

mysql-test/t/query_cache_debug.test:
  Wait for signal to be delivered.

mysql-test/r/query_cache_debug.result

@@ -153,7 +153,9 @@ SET DEBUG_SYNC="now WAIT_FOR parked1_2";
 ** until a broadcast signal reaches them causing both threads to 
 ** come alive and check the condition.
 SET DEBUG_SYNC="now SIGNAL go2";
+** Wait for thd2 to receive the signal
 SET DEBUG_SYNC="now SIGNAL go3";
+** Wait for thd3 to receive the signal
 **
 ** Finally signal the DELETE statement on THD1 one last time.
 ** The stmt will complete the query cache invalidation and return 

mysql-test/t/query_cache_debug.test

@@ -208,7 +208,17 @@ SET DEBUG_SYNC="now WAIT_FOR parked1_2";
 --echo ** until a broadcast signal reaches them causing both threads to 
 --echo ** come alive and check the condition.
 SET DEBUG_SYNC="now SIGNAL go2";
+--echo ** Wait for thd2 to receive the signal
+let $wait_condition=
+  SELECT COUNT(*) = 1 FROM information_schema.processlist
+  WHERE state = "Waiting for query cache lock";
+--source include/wait_condition.inc
 SET DEBUG_SYNC="now SIGNAL go3";
+--echo ** Wait for thd3 to receive the signal
+let $wait_condition=
+  SELECT COUNT(*) = 2 FROM information_schema.processlist
+  WHERE state = "Waiting for query cache lock";
+--source include/wait_condition.inc
 
 --echo **
 --echo ** Finally signal the DELETE statement on THD1 one last time.