CHECKSUM TABLE for performance schema tables could cause uninitialized
memory reads.

The root cause is a design flaw in the implementation of
mysql_checksum_table(), which do not honor null fields.

However, fixing this bug in CHECKSUM TABLE is risky, as it can cause the
checksum value to change.

This fix implements a work around, to systematically reset fields values
even for null fields, so that the field memory representation is always
initialized with a known value.

Before this fix, the test output for perfschema.server_init would
vary between executions, because some of the objects tested were
not guaranteed to exist in all configurations / code paths.

This fix removes these weak tests.

Also, comments referring to abandonned code have been cleaned up.

Before this fix, the server could crash inside a memcpy when reading data
from the EVENTS_WAITS_CURRENT / HISTORY / HISTORY_LONG  tables.

The root cause is that the length used in a memcpy could be corrupted,
when another thread writes data in the wait record being read.
Reading unsafe data is ok, per design choice, and the code does sanitize
the data in general, but did not sanitize the length given to memcpy.

The fix is to also sanitize the schema name / object name / file name
length when extracting the data to produce a row.

      
The crash during boot was caused by a DBUG_PRINT statement in fill_schema_schemata() (in
sql_show.cc). This DBUG_PRINT statement contained several instances of %s in the format 
string and for one of these we gave a NULL pointer as the argument. This caused the
call to vsnprintf() to crash when running on Solaris.
      
The fix for this problem is to replace the call to vsnprintf() with my_vsnprintf()
which handles that a NULL pointer is passed as argumens for %s.

This patch also extends my_vsnprintf() to support %i in the format string.

Implemented post review comments.

Added --force to the mysql_upgrade command in the test scripts,
so that the test output does not depends on whether other tests involving an
upgrade have been executed or not in the same test suite execution.

Before this fix, the server could crash during shutdown,
due to race conditions, that occured when killing the server.

In particular, the performance schema instrumentation handle,
PSI_server, and the performance schema itself would be cleaned up
too soon, causing race conditions with a running kill server thread.

The specifics of the race condition found are that:
the main thread executing "PSI_server= NULL" can cause crashes in
other threads still running, which are executing
"if (PSI_server != NULL) PSI_server->xxx()"
as part of the performance schema instrumentation.

While the bug was reported for the kill server thread,
in theory the same crash could happen with the signal thread,
as found by code analysis.

The correct fix would be to only shutdown the performance schema
and set PSI_server to NULL after every other thread is guaranteed
to be completed, including the kill_server_thread.

However, due to the existing mysqld server design, this is not the case.
See in particular bug number 56666.

The work around used to fix this race condition is to simply not
perform the call to shutdown_performance_schema() when the server exits,
and to keep the PSI_server pointer unchanged.

This will cause memory leaks to be reported by tools like valgrind,
but no memory leak actually happen because the process is about to exit().

As a result, the file mysql-test/valgrind.supp has been updated
to filter out these false positive messages.

This code has been tested with running in a loop the following
tests in parallel, which have been known to fail with race conditions
in the past:
- rpl_change_master
- binlog_max_extension
- events_restart
- rpl_heartbeat_basic
and no crash of test failure has been seen with the changed code.

Before this fix, it was possible to build the server:
- with the performance schema
- with a dummy implementation of my_atomic (MY_ATOMIC_MODE_DUMMY).

In this case, the resulting binary will just crash,
as this configuration is not supported.

This fix enforces that the build will fail with a compilation error in this
configuration, instead of resulting in a broken binary.

mysys/my_sync.c: In function 'my_sync_dir':
mysys/my_sync.c:103:29: error: unused parameter 'dir_name'
mysys/my_sync.c:103:43: error: unused parameter 'my_flags'
mysys/my_sync.c: In function 'my_sync_dir_by_file':
mysys/my_sync.c:144:37: error: unused parameter 'file_name'
mysys/my_sync.c:144:52: error: unused parameter 'my_flags'

mysys/my_gethwaddr.c: In function 'my_gethwaddr':
mysys/my_gethwaddr.c:67:11: error: pointer targets in assignment differ in signedness

Add a virtual destructor. Class has virtual functions.

With recent changes in the performance schema default sizing parameters,
the memory used by a mysqld binary increased accordingly.

This negatively affects the MTR test suite,
because running several tests in parallel now consumes more ressources.

The fix is to leave the default production values unchanged,
and to configure the MTR environment to limit memory
used when running tests in the test suite, which is ok
because only a few objects are typically used within a test script.

This fix:
- changed the default configuration in MTR to use less memory
- adjusted the performance schema tests accordingly

Note that 1,000 mutex instances was too short and caused test failures
in the past in team trees, so the default used is now 10,000 in MTR.

The amount of memory used by the performance schema itself
can be observed with the statement SHOW ENGINE PERFORMANCE_SCHEMA STATUS

The Item_func_str_to_date class wasn't providing correct integer DATETIME
representation as expected. This led to wrong comparison result and didn't
allowed the STR_TO_DATE function to be used with indexes.
Also, STR_TO_DATE function was inconsisted on throwing warnings/errors.
Fixed now.

val_int and result_as_longlong methods were added to the Item_func_str_to_date
class. 

      
In sql/log.c, member function wait_for_update_bin_log, a condition is entered with
THD::enter_cond but is not exited. This might leave dangling references to the
mutex/condition in the per-thread information area.
      
To fix the problem, we call exit_cond to properly remove references to the mutex,
LOCK_log.

On Solaris with version 3.4.6, the ha_example.so shared library is built
with DTrace and the server is built without DTrace support. This occurs
because dtrace.cmake disables DTrace support for 3.4.6, but still set
HAVE_DTRACE, which causes probes_mysql.h to include probes_mysql_dtrace.h
instead of probes_mysql_nodtrace.h.

This patch fixes this by not setting HAVE_DTRACE on Solaris for GCC 3.4.6.

 create data dir correctly in initial_database target on Windows
 handle case where INSTALL_MYSQLTESTDIR is empty (e.g someone does not want
 to install tests)

          thread-specific variables weren't set when we load error message files.

per-file comments:
  libmysqld/lib_sql.cc
Bug#53251      mysql_library_init fails on second execution with embedded library
      we need to call my_thread_init() once more. Normally it's called at the my_init()
      stage but that doesn't happen on the second my_init() call.

  sql/derror.cc
Bug#53251      mysql_library_init fails on second execution with embedded library
     use default errors for the embedded server.

  sql/mysqld.cc
Bug#53251      mysql_library_init fails on second execution with embedded library
        unregister server errors in clean_up(). Without it the error list contains
        that on the second mysql_server_init() which is not good.

  sql/set_var.cc
Bug#53251      mysql_library_init fails on second execution with embedded library
        sys_var::cleanup() call instead of the destructor

  sql/set_var.h
Bug#53251      mysql_library_init fails on second execution with embedded library
        sys_var::cleanup() introduced instead of the destructor
        
  sql/sys_vars.h
Bug#53251      mysql_library_init fails on second execution with embedded library
        Sys_var_charptr::cleanup() implemented

Merge cleanup, fixed a build warning:

my_getopt.c:156: warning: 'opt_found' may be used uninitialized in this function

        When in embedded-serve mode, mysqltest tried to run '--send' commands in the separate thread.
        That upsets some engines (InnoDB particularly) as the transaction has to be executed in the same
        thread completely. So i implemented some different approach. So we create one separate thread for
        each connection and execute all the queries of this connection inside it. Looks even simpler than it was
        for me.

per-file comments:
  client/mysqltest.cc
Bug#54861      Additional connections not handled properly in mtr --embedded
        Now the connection has one running connection_thread() attached. And sends all the
        query and read-result requests to it.

       made libmysqld/Makefile.am to have same licence as libmysqld/CMakeLists.txt

per-file comments:
  libmysqld/Makefile.am
Bug#54906      Inconsistent license of libmysqld
        Added GPL license header instead of Library GPL.

Problem:
- ORDER BY for utf8mb4_bin, utf16_bin and utf32_bin returned
  results in a wrong order, because old functions
  (supporting only BMP range) were used to handle these collations.
- Additionally, utf16_bin did not sort supplementary characters
  between U+D700 and U+E000, as WL#1213 specification specified.

            "Access compatibility" syntax

The "wild" "DELETE FROM table_name.* ... USING ..." syntax
for multi-table DELETE statements is documented but it was
lost in the fix for the bug 30234.

The table_ident_opt_wild parser rule has been added
to restore the lost syntax.