1 - MASTER_MYSOCK fixed inexistent environment variable.
  2 - Fixed mismatch in result files due to changes in MTR.

mysql-test/r/change_user.result:
  Update test case result.
mysql-test/r/not_embedded_server.result:
  Update test case result.
mysql-test/t/change_user.test:
  Move newer (and better) version of the test case.
mysql-test/t/not_embedded_server.test:
  Move this test case over to change_user.test
  This version is deterministic.

      
The test case proposed by the bugfix fails in bugteam trees after merging new 
mtr from main. The failure is due to the fact that the binlog file location has
changed and is no more under $MYSQLTEST_VARDIR/log.
      
This patch fixes the test failure by setting the correct path to the binlog 
file.

test case was executed.

mysql-test/include/concurrent.inc:
  Drop created user.
mysql-test/r/concurrent_innodb_safelog.result:
  Update test case result.
mysql-test/r/concurrent_innodb_unsafelog.result:
  Update test case result.

mysql-test/r/cache_innodb.result:
  Update test case result.

test case was executed.

mysql-test/r/func_compress.result:
  Update test case result.
mysql-test/r/innodb_bug34300.result:
  Update test case result.
mysql-test/t/func_compress.test:
  Disconnect connection and reset max_allowed_packet to it's
  default value.
mysql-test/t/innodb_bug34300.test:
  Disconnect connection and reset max_allowed_packet to it's
  default value and enable query log.

conflicts:
  Text conflict in mysql-test/suite/sys_vars/r/rpl_max_binlog_size_func.result
  Text conflict in mysql-test/suite/sys_vars/t/rpl_max_binlog_size_func.test

 - Increase number of transaction objects available in ndbd
 - Most likely this is a timing related issue.

Temporarily blocking to run the test on windows.

Todo: remove the include upon setup_fake_relay_log has been fixed.


mysql-test/suite/rpl/t/rpl_cross_version.test:
  blocking to run the test on windows for a while.

BUG#41003 reached our trees.

            
If the system time is adjusted back during a query execution
(resulting in the end time being earlier than the start time)
the code that prints to the slow query log gets confused and 
prints unsigned negative numbers.
            
Fixed by not logging the statements that would have negative
execution time due to time shifts.
No test case since this would involve changing the system time.

sql/sql_parse.cc:
  Bug #35396: don't log queries with negative execution times 
  (due to shifts in system time).

      
After the earlier fix, mtr tests reports "table full" messages as warnings. This is 
expected, this patch fixes the mtr testframework to ignore the error message.

mysql-test/lib/mtr_report.pl:
  fixed mtr_report_stats to ignore the Table Full error messages generated by the testcases main.almost_full, main.myisam_data_pointer_size_func

Item_in_optimizer::is_null() evaluated "NULL IN (SELECT ...)" to NULL regardless of
whether subquery produced any records, this was a documented limitation.

The limitation has been removed (see bugs 8804, 24085, 24127) now
Item_in_optimizer::val_int() correctly handles all cases with NULLs. Make
Item_in_optimizer::is_null() invoke val_int() to return correct values for
"NULL IN (SELECT ...)".


mysql-test/r/subselect.result:
  BUG#37822: Correlated subquery with IN and IS UNKNOWN provides wrong result
  - Testcase
mysql-test/t/subselect.test:
  BUG#37822: Correlated subquery with IN and IS UNKNOWN provides wrong result
  - Testcase

            messed up

"ROW(...) IN (SELECT ... FROM DUAL)" always returned TRUE.

Item_in_subselect::row_value_transformer rewrites "ROW(...)
IN SELECT" conditions into the "EXISTS (SELECT ... HAVING ...)"
form.
For a subquery from the DUAL pseudotable resulting HAVING
condition is an expression on constant values, so further
transformation with optimize_cond() eliminates this HAVING
condition and resets JOIN::having to NULL.
Then JOIN::exec treated that NULL as an always-true-HAVING
and that caused a bug.

To distinguish an optimized out "HAVING TRUE" clause from
"HAVING FALSE" we already have the JOIN::having_value flag.
However, JOIN::exec() ignored JOIN::having_value as described
above as if it always set to COND_TRUE.

The JOIN::exec method has been modified to take into account
the value of the JOIN::having_value field.


mysql-test/r/subselect3.result:
  Added test case for bug #39069.
mysql-test/t/subselect3.test:
  Added test case for bug #39069.
sql/sql_select.cc:
  Bug #39069: <row constructor> IN <table-subquery> seriously
              messed up
  
  The JOIN::exec method has been modified to take into account
  the value of the JOIN::having_value field.