- BUG#22306: STOP INSTANCE can not be applied for instances in Crashed,
    Failed and Abandoned;
  - BUG#23476: DROP INSTANCE does not work
  - BUG#23215: STOP INSTANCE takes too much time

BUG#22306:
The problem was that STOP INSTANCE checked that mysqld is up and running.
If it was not so, STOP INSTANCE reported an error. Now, STOP INSTANCE
reports an error if the instance has been started (mysqld can be down).

BUG#23476:
The problem was that DROP INSTANCE tried to stop inactive instance. The fix is
trivial.

BUG#23215:
The problem was that locks were not acquired properly, so the
instance-monitoring thread could not acquire the mutex, holded by the
query-processing thread.

The fix is to simplify locking scheme by moving instance-related information to
Instance-class out of Guardian-class. This allows to get rid of storing a
separate list of Instance-information in Guardian and keeping it synchronized
with the original list in Instance_map.

into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  bodhi.local:/opt/local/work/mysql-4.1-runtime

into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge

into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge

  Changed paths to ndb include directory to include "storage"
Makefile.am:
  Adjusted path to yaSSL libtool libraries
ssl.m4:
  Use libtool way of specifying yaSSL libraries

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug20637

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug20637

into  mysql.com:/home/kent/bk/mysql-5.1-build

into  mysql.com:/home/kent/bk/mysql-5.1-build

into  mysql.com:/home/kent/bk/mysql-5.1-build

into  mysql.com:/home/kent/bk/mysql-5.0-build

Note that we ignore CONCURRENT if LOAD DATA CONCURRENT is used from
inside a stored routine and MySQL is compiled with Query Cache support
(this is not in the manual).

The problem was that the condition test of "we are inside stored routine"
was reversed, thus CONCURRENT _worked only_ from stored routine.  The
solution is to use proper condition test.

No test case is provided because the test case would require a large
amount of input, and it's hard to tell is SELECT is really blocked or
just slow (subject to race).

into  kahlann.erinye.com:/home/df/mysql/build/mysql-4.1-build-work

into  kahlann.erinye.com:/home/df/mysql/build/mysql-5.0-build-work

into  kahlann.erinye.com:/home/df/mysql/build/mysql-5.1-build

into  kahlann.erinye.com:/home/df/mysql/build/mysql-5.0-build-work

into  dl145s.mysql.com:/data0/bk/team_tree_merge/MERGE/mysql-5.1-opt

into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  kahlann.erinye.com:/home/df/mysql/build/mysql-5.1-build

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  bodhi.local:/opt/local/work/mysql-4.1-runtime

into  mysql.com:/home/kent/bk/mysql-5.1-build

into  bodhi.local:/opt/local/work/mysql-5.1-24486

into  kahlann.erinye.com:/home/df/mysql/build/mysql-5.1-build-merge

deadlock_innodb:events_grant". This was a memory leak introduced by 
the patch for Bug 22830.
Post-review fixes.

into  trift2.:/MySQL/M50/push-5.0

into  trift2.:/MySQL/M50/push-5.0

into  mysql.com:/home/kent/bk/mysql-5.1-build

into  mysql.com:/home/kent/bk/mysql-5.0-build