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.

      
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.

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.

                  
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

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.

There was a missing initialization.

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.

                  
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.

by using and taking out a full path.

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.

            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.

      
The SHOW VARIABLES LIKE .../SELECT @@/SELECT ... FROM INFORMATION_SCHEMA.VARIABLES
were assuming that all the system variables are in system charset (UTF-8).
However the variables that are settable through command line will have a different
character set (character_set_filesystem).
Fixed the server to remember the correct character set of basedir, datadir, tmpdir,
ssl, plugin_dir, slave_load_tmpdir, innodb variables; init_connect and init_slave 
variables and use it when processing data.