rqg_mdl_stability".

When start of statement's waiting on a metadata lock 
created more than one loop in waiters graph server might 
have entered deadlock condition.

The problem was that in the case described above MDL deadlock 
detector had to perform several searches for deadlock but
forgot to reset Deadlock_detection_context before performing 
new search. 
Failure to do so has broken assumption in code resposible for 
choosing victim that if Deadlock_detection_context::victim
is set we also have read lock on m_waiting_for_lock for this
context. As result this lock could have been unlocked more
times than it was acquired which corrupted rwlock's state
which led to server deadlock.

This fix ensures that such reset is done before each attempt
to find a deadlock.

mysql-test/r/mdl_sync.result:
  Added test for bug #50998 "Deadlock in MDL code during test
  rqg_mdl_stability" as well as coverage for the case when
  addition of statement waiting for metadata lock adds several
  loops in the waiters graph and therefore several searches
  for deadlock should be performed by MDL deadlock detector.
mysql-test/t/mdl_sync.test:
  Added test for bug #50998 "Deadlock in MDL code during test
  rqg_mdl_stability" as well as coverage for the case when
  addition of statement waiting for metadata lock adds several
  loops in the waiters graph and therefore several searches
  for deadlock should be performed by MDL deadlock detector.
sql/mdl.cc:
  Ensure that in cases when MDL deadlock detector had to
  perform several searches for deadlock because several loops
  in waiters graph are possible we reset
  Deadlock_detection_context before performing each search.
  Failure to do so has broken assumption in code resposible
  for choosing victim that if Deadlock_detection_context::victim
  is set we also have read lock on m_waiting_for_lock for this
  context. As result this lock could have been unlocked more
  times than it was acquired which corrupted rwlock's state
  (no one was able to acquire write lock on it anymore).