Adding --loose-skip-falcon option to the mysqld options provided by MTR (v2) during mysqld bootstrap in order to avoid plugin (in this case Falcon) initialization of static variables etc. Options --loose-skip-innodb and --loose-skip-ndbcluster were already included.

This will fix Bug#41014 (falcon_bug_39708 fails in pushbuild in 6.0-rpl: "succeeded - should have failed")
in the case of MTR v2 (which currently is available in -rpl branches only). 
MTR v1 (e.g. in main 6.0 branch) does not have this problem.

It would be more ideal to remove the --loose-skip-* options and provide a single option disabling all plugin initialization instead, or have bootstrap do this by default. Server modifications are (most likely) needed to be able to do that.


mysql-test/mysql-test-run.pl:
  Reintroduced the --loose-skip-falcon bootstrap option used by the previous version of this test runner.

      
The test reacted on the way how mtr orders arguments for the server
that are gathered from different source. It appeared that the opt-file
options were parsed before those that supplied to mtr via its command
line. In effect, the opt-file preferences got overriden by the command
line and some tests, like no-threads, were caught by surprise: a test
expects an option value that had been "hardcoded" into its opt-file
but gets another one.
This server options ordering problem exists on in the new rpl trees
mtr.  In option of the author of this patch, the opt-file shall be
considered as having the highest preference weight. The opt-file is
merely a part of the header of a test, namely a part that can not be
technically deployed along the test file.
It's unnatural for the test writer to provide both the opt file value
and a guard that guarantees the value will be set on in the run time.
It's logical to provide either one: the option and its value or the
guard.

Fixed with relocating parse of the opt file to be the last among
sources of the sever's options.

A side effect: fixing a small problem of resetting the suite options
at time the opt file starts parsing.

A side effect: main.log_bin_trust_function_creators_func is disabled to
be re-enabled with the fixes for bug#41003 will be merged from the main trees.


mysql-test/lib/mtr_cases.pm:
  Relocating parse of the opt file to be the last. This ensure the opt file is the last
  provider for the server options so that the opt-file options have the highest preference;
  fixing a separate issue of incorrect resetting the suite options for the server;
mysql-test/t/disabled.def:
  log_bin_trust_function_creators_func is disabled. Todo: to-reable when fixes for bug#41003
  will be merged from the main trees.

exact number of error. The patch does following:
1) Add new parameter $slave_sql_errno for wait_for_slave_sql_error.inc
2) Add waiting error 1062 (Duplicate PK) for slave SQL thread in test case.

where timeout can happen:
1. Added waiting start/stop slave to make sure that slave works properly.
2. Added cleanup for slave.
3. Updated related result files.

sync_with_master command. The patch add waiting of proper state of slave 
before sync with master.

mysql-test/include/wait_until_disconnected.inc:
  Change the default value for $mysql_errno so that the loops is run at least once

mysql-test/include/mtr_warnings.sql:
  Slice the time the takes to load the servers error log into error_log table
  by using a declared variable instead of user variable.
  Also change the while loop to only do one LOCATE per loop.
  Drop the temporary tables created by sp

                  
The problem here is that embedded server starts handle_thread manager 
thread  on mysql_library_init() does not stop it on mysql_library_end().
At shutdown, my_thread_global_end() waits for thread count to become 0,
but since we did not stop the thread it will give up after 5 seconds.
             
Solution is to move shutdown for handle_manager thread from kill_server()
(mysqld specific) to clean_up() that is used by both embedded and mysqld.
            
This patch also contains some refactorings - to avoid duplicate code,
start_handle_manager() and stop_handle_manager() functions are introduced.
Unused variables are eliminated. handle_manager does not rely on global
variable abort_loop anymore to stop (abort_loop is not set for embedded).
            
Note: Specifically on Windows and when using DBUG version of libmysqld, 
the complete solution requires removing obsolete code my_thread_init() 
from my_thread_var(). This has a side effect that a DBUG statement 
after my_thread_end() can cause thread counter to be incremented, and 
embedded will hang for some seconds. Or worse, my_thread_init() will 
crash if critical sections have been deleted by the global cleanup 
routine that runs in a different thread. 

This patch also fixes and revert prior changes for Bug#38293 
"Libmysqld crash in mysql_library_init if language file missing".

Root cause of the crash observed in Bug#38293  was bug in my_thread_init() 
described above




client/mysql.cc:
  sql_protocol_typelib is not exported from libmysqld
  (does not make sense either)
  thus excluded from embedded client
dbug/dbug.c:
  revert changes for Bug#38293
include/my_dbug.h:
  revert changes for Bug#38293
libmysql/libmysql.c:
  Removed DBUG_POP call, because when called after my_end(), will access
  THR_key_mysys that is already deleted. The result of pthread_get_specific
  is not predictable in this case and hence DBUG_POP can crash.
libmysqld/examples/CMakeLists.txt:
  Revert changes for Bug#38293.
libmysqld/lib_sql.cc:
  code to start handle manager is factored out into 
  start_handle_manager() function
libmysqld/libmysqld.def:
  Revert changes for Bug #38293
  Remove excessive exports from libmysqld, export what API documents.
mysys/my_thr_init.c:
  Remove windows-DLL-specific workaround for something (old code, no documentation for
  what specifically). The problem is that even after my_thread_end() is finished, 
  DBUG statement can initiate my_thread_init(). This does not happen anywhere else and 
  should not happen on  Windows either.
sql/mysql_priv.h:
  - new functions start_handle_manager() and stop_handle_manager()
  - move manager_thread_in_use  variable to sql_manager.cc and made
  it static
  - remove manager_status, as it is unused
sql/mysqld.cc:
  Code to start/stop handle_manager thread is factored out into start_handle_manager()

Added text "Test ended at <time>" after failure reports

BUG#39382: innodb_max_dirty_pages_pct_func failed with timeout on pushbuild
Disabled innodb_max_dirty_pages_pct_func.
Please re-enable if the test gets fixed.


mysql-test/t/disabled.def:
  Disabled innodb_max_dirty_pages_pct_func.

There was a missing initialization.

sql/set_var.h:
  Added an initialization missing during the merge of 37339.

with non-RSA-requesting client if server uses RSA key

matchSuite() may not find a match. 
It will return error in this case.
Added a error checking code that will prevent using uninitialized 
memory in the code based on the assumption 
that matchSuite() has found a match.

extra/yassl/src/yassl_imp.cpp:
  Bug #39178: Correct error checking added

                  
Updated MySQL time handling code to react correctly on UTC leap second additions.
MySQL functions that return the OS current time, like e.g. CURDATE(), NOW() etc
will return :59:59 instead of :59:60 or 59:61.
As a result the reader will receive :59:59 for 2 or 3 consecutive seconds 
during the leap second.
This fix will not affect the values returned by UNIX_TIMESTAMP() for leap seconds.
But note that when converting the value returned by UNIX_TIMESTAMP() to broken 
down time the correction of leap seconds will still be applied.
Note that this fix will make a difference *only* if the OS is specially configured
to return leap seconds from the OS time calls or when using a MySQL time zone 
defintion that has leap seconds.
Even after this change date/time literals (or other broken down time 
representations) with leap seconds (ending on :59:60 or 59:61) will still be 
considered illegal and discarded by the server with an error or 
a warning depending on the sql mode.
Added a test case to demonstrate the effect of the fix.

mysql-test/r/timezone3.result:
  Bug #39920: test case
mysql-test/std_data/Moscow_leap:
  Bug #39920: updated the Moscow time zone to Dr. Olson's tzdata 2008i 
  to accomodate for the 2008 leap second
mysql-test/t/timezone3.test:
  Bug #39920: test case
sql/tztime.cc:
  Bug #39920: adjust leap seconds (:60 or :61) to :59
sql/tztime.h:
  Bug #39920: adjust leap seconds (:60 or :61) to :59

by using and taking out a full path.

mysql-test/r/ctype_filesystem.result:
  Bug #37399: use MYSQL_TEST_DIR rooted test
mysql-test/t/ctype_filesystem-master.opt:
  Bug #37399: use MYSQL_TEST_DIR rooted test
mysql-test/t/ctype_filesystem.test:
  Bug #37399: use MYSQL_TEST_DIR rooted test

TABLE_LIST doesn't free Strings in its string lists
(TABLE_LIST::use_index and TABLE_liST::ignore_index), so
calling c_ptr_safe() on that Strings leads to memleaks.
OTOH "safe" c_ptr_safe() is not necessary there and we can
replace it with c_ptr().

Diff to actual 5.0-bugteam is revno: 2725 only

            leads to an assertion failure

Any run-time error in stored function (like recursive function
call or update of table that is already updating by statement
which invoked this stored function etc.) that was used in some
expression of the single-table UPDATE statement caused an
assertion failure.
Multiple-table UPDATE (as well as INSERT and both single- and
multiple-table DELETE) are not affected.


mysql-test/r/update.result:
  Added test case for bug #40745.
mysql-test/t/update.test:
  Added test case for bug #40745.
sql/sql_update.cc:
  Bug #40745: Error during WHERE clause calculation in UPDATE
              leads to an assertion failure
  
  The mysql_update function has been updated to take into account
  the status of invoked stored functions before setting the status
  of whole UPDATE query to OK.

            an error

Even after the fix for bug 28701 visible behaviors of
SELECT FROM a view and SELECT FROM a regular table are
little bit different:

1. "SELECT FROM regular table USE/FORCE/IGNORE(non
   existent index)" fails with a "ERROR 1176 (HY000):
   Key '...' doesn't exist in table '...'"

2. "SELECT FROM view USING/FORCE/IGNORE(any index)" fails
   with a "ERROR 1221 (HY000): Incorrect usage of
   USE/IGNORE INDEX and VIEW".  OTOH "SHOW INDEX FROM
   view" always returns empty result set, so from the point
   of same behaviour view we trying to use/ignore non
   existent index.

To harmonize the behaviour of USE/FORCE/IGNORE(index)
clauses in SELECT from a view and from a regular table the
"ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
and VIEW" message has been replaced with the "ERROR 1176
(HY000): Key '...' doesn't exist in table '...'" message
like for tables and non existent keys.


mysql-test/r/view.result:
  Added test case for bug #33461.
  Updated test case for bug 28701.
mysql-test/t/view.test:
  Added test case for bug #33461.
  Updated test case for bug 28701.
sql/sql_view.cc:
  Bug #33461: SELECT ... FROM <view> USE INDEX (...) throws
              an error
  
  To harmonize the behaviour of USE/FORCE/IGNORE(index)
  clauses in SELECT from a view and from a regular table the
  "ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
  and VIEW" message has been replaced with the "ERROR 1176
  (HY000): Key '...' doesn't exist in table '...'" message
  like for tables and non existent keys.