Kill mysqltest and call mtr_kill_leftovers() before terminating

conflicts:
   conflict      sql/sql_prepare.cc

In Prepared_statement::prepare() bail out as soon as
parser_state.init() fails, trying to continue leads to crashes.

conflicts:
   conflict      mysys/safemalloc.c
   conflict      sql/mysqld.cc
   conflict      sql/sp.cc
   conflict      sql/sql_lex.cc
   conflict      sql/sql_lex.h
   conflict      sql/sql_parse.cc
   conflict      sql/sql_prepare.cc

conflicts:
   conflict      sql/sql_parse.cc

conflicts:
   conflict      sql/sql_parse.cc

Item*) at opt_sum.cc:305
      
Queries applying MIN/MAX functions to indexed columns are
optimized to read directly from the index if all key parts
of the index preceding the aggregated key part are bound to
constants by the WHERE clause. A prefix length is also
produced, equal to the total length of the bound key
parts. If the aggregated column itself is bound to a
constant, however, it is also included in the prefix.

Such full search keys are read as closed intervals for
reasons beyond the scope of this bug. However, the procedure
missed one case where a key part meant for use as range
endpoint was being overwritten with a NULL value destined
for equality checking. In this case the key part was
overwritten but the range flag remained, causing open
interval reading to be performed.

Bug was fixed by adding more stringent checking to the
search key building procedure (matching_cond) and never
allow overwrites of range predicates with non-range
predicates.

An assertion was added to make sure open intervals are never
used with full search keys.

            strict aliasing violations.

One somewhat major source of strict-aliasing violations and
related warnings is the SQL_LIST structure. For example,
consider its member function `link_in_list` which takes
a pointer to pointer of type T (any type) as a pointer to
pointer to unsigned char. Dereferencing this pointer, which
is done to reset the next field, violates strict-aliasing
rules and might cause problems for surrounding code that
uses the next field of the object being added to the list.

The solution is to use templates to parametrize the SQL_LIST
structure in order to deference the pointers with compatible
types. As a side bonus, it becomes possible to remove quite
a few casts related to acessing data members of SQL_LIST.

           strict aliasing violations.

Essentially, the problem is that large parts of the server were
developed in simpler times (last decades, pre C99 standard) when
strict aliasing and compilers supporting such optimizations were
rare to non-existent. Thus, when compiling the server with a modern
compiler that uses strict aliasing rules to perform optimizations,
there are several places in the code that might trigger undefined
behavior.

As evinced by some recent bugs, GCC does a somewhat good of job
misoptimizing such code, but on the other hand also gives warnings
about suspicious code. One problem is that the warnings aren't
always accurate, yet we can't afford to just shut them off as we
might miss real cases. False-positive cases are aggravated mostly
by casts that are likely to trigger undefined behavior.

The solution is to start a cleanup process focused on fixing and
reducing the amount of strict-aliasing related warnings produced
by GCC and others compilers. A good deal of noise reduction can
be achieved by just removing useless casts that are product of
historical cruft and are likely to trigger undefined behavior if
dereferenced.

Revision ID of the patch: marc.alff@oracle.com-20100608124148-lr1ult7lwo75niev

text conflict: unittest/examples/Makefile.am

The bug was caused by buffered output. Flushing resolved it.
We still recommend to allways call plan().
  
Also fix some compile warnings (formal parameter different from declaration)

Addendum: Work around a compilation failure on Windows due to
          windows.h not being added to the global namespace.

Problem: the server missed the fact that one can read from 
2 indexes alternately using HANDLER interface.

Fix: check if the same (initialized) index is involved
reading next/prev values from the index.

The problem was that the bundled yaSSL library was being built
without thread safety support regardless of the thread safeness
of the compoments linked with it.

The solution is to enable yaSSL thread safety support if any
component (server or client) is to be built with thread support.

Also, generate new certificates for yaSSL's test suite.

Prior to this fix, mysys mutexes such as THR_LOCK_lock could be initialized
twice by a call to my_init().
The root cause was out of place initialization in my_basic_init(),
calling my_thread_global_init().

With this fix,
- my_basic_init() properly initializes the mutex implementation itself,
for SAFE or FAST mutexes, and for platform dependent initializations,
before initialiazing a mutex.
- my_init() properly initializes mysys mutexes once,
when making the first call to my_thread_global_init().