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.

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.

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.

Logging slow stored procedures caused the slow log to write 
very large lock times. The lock times was a result of a 
negative number being cast to an unsigned integer.
The reason the lock time appeard negative was because 
one of the measurements points was reset after execution
causing it to change order with the start time of the 
statement.
      
This bug is related to bug 47905 which in turn was 
introduced because of a joint fix for 12480,12481,12482 and 11587.

The fix is to only reset the start_time before any statement
execution in a SP while not resetting start_utime or
utime_after_lock which are used for measuring the 
performance of the SP. Start_time is used to set the
timestamp on the replication event which controlls how
the slave interprets time functions like NOW().

The problem is in the Item_func_isnull::update_used_tables() function,
bracket is at the wrong place. Because of that isnull item erroneously
is treated as const item. The fix is to set brackets in the right place.

when an out-of-supported-range date is detected.

NET::skip_big_packet isn't defined for the embedded server,
hide it in such a case.

            
Some of the server implementations don't support dates later
than 2038 due to the internal time type being 32 bit.
Added checks so that the server will refuse dates that cannot
be handled by either throwing an error when setting date at 
runtime or by refusing to start or shutting down the server if 
the system date cannot be stored in my_time_t.

Patch for bug#52913: Inserted check if mysqlhotcopy script is existing as requested by review. DIsabled the test until bug#54129 will befixed.

Post-push fix.

  
Post-push fix.
  
There was a valgrind issue on the loop that checks whether there
are NULL fields in the UNIQUE KEY or not. In detail, for the last 
iteration the server may read out of the key_part array boundaries,
making valgrind to output warnings.

We fix this by correcting the loop, ie, moving the part that reads
from the key_part to be inside the loop statement block. This way
the assignment is protected by the loop condition.

When using Unique Keys with nullable parts in RBR, the slave can
choose the wrong row to update. This happens because a table with
an unique key containing nullable parts cannot strictly guarantee 
uniqueness. As stated in the manual, for all engines, a UNIQUE 
index allows multiple NULL values for columns that can contain 
NULL.

We fix this at the slave by extending the checks before assuming
that the row found through an unique index is is the correct
one. This means that when a record (R) is fetched from the storage
engine and a key that is not primary (K) is used, the server does 
the following: 

 - If K is unique and has no nullable parts, it returns R;
 - Otherwise, if any field in the before image that is part of K
   is null do an index scan;
 - If there is no NULL field in the BI part of K, then return R.

A side change: renamed the existing test case file and added a
test case covering the changes in this patch.

MTR will ignore fully qualified test name entries in disabled.def 
lists. Therefore, it would still run the test case, even if it is
listed.

This patch fix this by extending the check when marking the test
case as disabled to take into consideration not only the cases that
contain the simple test name but also those that contain fully 
qualified test names.

result file differs on embedded

Field_time::get_date method does not initialize MYSQL_TIME::time_type field.
The fix is to init this field.

            and .tar.gz, windows vs linux..

On Intel x86 machines index selection by the MySQL query
optimizer could sometimes depend on the compiler version and
optimization flags used to build the server binary.

The problem was a result of a known issue with floating point
calculations on x86: since internal FPU precision (80 bit)
differs from precision used by programs (32-bit float or 64-bit
double), the result of calculating a complex expression may
depend on how FPU registers are allocated by the compiler and
whether intermediate values are spilled from FPU to memory. In
this particular case compiler versions and optimization flags
had an effect on cost calculation when choosing the best index
in best_access_path().

A possible solution to this problem which has already been
implemented in mysql-trunk is to limit FPU internal precision
to 64 bits. So the fix is a backport of the relevant code to
5.1 from mysql-trunk.

err_index could be not a member of the share structure or prebuilt
structure passed from MySQL. For now, we resort to the traditional
way of scanning index->table for the index number.