Install procedure does not copy *.inc files located under the mysql-test/t directory.
Therefore, this patch moves the rpl_trigger.inc to the mysql-test/include directory.

The test case fails sporadically on Windows while trying to overwrite an unused
binary log. The problem stems from the fact that MySQL on Windows does not
immediately unlock/release a file while the process that opened and closed it is
still running. In BUG 38603, this issue was circumvented by stopping the MySQL
process, copying the file and then restarting the MySQL process. 

Unfortunately, such facilities are not available in the 5.0.  Other approaches
such as stopping the slave and issuing change master do not work because the relay
log file and index are not closed when a slave is stopped. So to fix the problem,
we simply don't run on windows the part of the test that was failing.

http://lists.mysql.com/commits/53569

engine to the partition_csv test. Also remove test case that was
duplicated. Fix connection procedure with the embedded server.

- Define and pass compile time path variables as pre-processor definitions to 
  mimic the makefile build.
- Set new CMake version and policy requirements explicitly.
- Changed DATADIR to MYSQL_DATADIR to avoid conflicting definition in 
  Platform SDK header ObjIdl.h which also defines DATADIR.

            when used with --tab

1) New syntax: added CHARACTER SET clause to the
  SELECT ... INTO OUTFILE (to complement the same clause in
  LOAD DATA INFILE).
  mysqldump is updated to use this in --tab mode.

2) ESCAPED BY/ENCLOSED BY field parameters are documented as
   accepting CHAR argument, however SELECT .. INTO OUTFILE
   silently ignored rests of multisymbol arguments.
   For the symmetrical behavior with LOAD DATA INFILE the
   server has been modified to fail with the same error:

     ERROR 42000: Field separator argument is not what is
                  expected; check the manual

3) Current LOAD DATA INFILE recognizes field/line separators
   "as is" without converting from client charset to data
   file charset. So, it is supposed, that input file of
   LOAD DATA INFILE consists of data in one charset and
   separators in other charset. For the compatibility with
   that [buggy] behaviour SELECT INTO OUTFILE implementation
   has been saved "as is" too, but the new warning message
   has been added:

     Non-ASCII separator arguments are not fully supported

   This message warns on field/line separators that contain
   non-ASCII symbols.

If using statement based replication (SBR), repeatedly calling
statements which are unsafe for SBR will cause a warning message
to be written to the error for each statement. This might lead
to filling up the error log and there is no way to disable this
behavior.

The solution is to only log these message (about statements unsafe
for statement based replication) if the log_warnings option is set.

For example:

SET GLOBAL LOG_WARNINGS = 0;
INSERT INTO t1 VALUES(UUID());
SET GLOBAL LOG_WARNINGS = 1;
INSERT INTO t1 VALUES(UUID());

In this case the message will be printed only once:

[Warning] Statement may not be safe to log in statement format.
          Statement: INSERT INTO t1 VALUES(UUID())

We disallow the partitioning of a log table. You could however
partition a table first, and then point logging to it. This is
not only against the docs, it also crashes the server.

We catch this case now.

Initialize LOCK_open as a adapative mutex on platforms where the
PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP macro is available. The flag
indicates that a thread should spin (busy wait) for some time on a
locked adaptive mutex before blocking (sleeping). It's intended to
to alleviate performance problems due to LOCK_open being a highly
contended mutex.

      
A REPLACE in the MERGE engine is actually a REPLACE
into one (FIRST or LAST) of the underlying MyISAM
tables. So in effect the server works on the meta
data of the MERGE table, while the real insert happens
in the MyISAM table.

The MERGE table has no index, while MyISAM has a
unique index. When a REPLACE into a MERGE table (
and the REPLACE conflicts with a duplicate in a
child table) is done, we try to access the duplicate
key information for the MERGE table. This information
actually does not exist, hence this results in a crash.

The problem can be resolved by modifying the MERGE
engine to provide us the duplicate key information
directly, instead of just returning the MyISAM index
number as the error key. Then the SQL layer (or "the
server") does not try to access the key_info of the
MERGE table, which does not exist.

The current patch modifies the MERGE engine to provide
the position for a record where a unique key violation
occurs.

Fixed wrong prototype declaration which cased build failure on solaris.

          an assertion in a debug build.

The reason is that the C API doesn't support multiple result sets for prepared
statements and attempting to execute a stored routine which returns multiple result
sets sometimes lead to a network error. The network error sets the diagnostic area
prematurely which later leads to the assert when an attempt is made to set a second
server state.

This patch fixes the issue by changing the scope of the error code returned by
sp_instr_stmt::execute() to include any error which happened during the execution.
To assure that Diagnostic_area::is_sent really mean that the message was sent all
network related functions are checked for return status.

Bug#46354, when defining partitions without subpartition definition after defining it with the first partition and using list partition caused crash, fixed by more error checks in parser

those keywords do nothing in 5.1 (they are meant for future versions, for example featuring the Maria engine)
so they are here removed from the syntax. Adding those keywords to future versions when needed is:
- WL#5034 "Add TRANSACTIONA=0|1 and PAGE_CHECKSUM=0|1 clauses to CREATE TABLE"
- WL#5037 "New ROW_FORMAT value for CREATE TABLE: PAGE"

consumption (CPU) for upgrading a large log table can be intense.
Therefore, truncate the general_log table beforehand if running
mysql_upgrade test with Valgrind.

            compression 
 
Since uint3korr() may read 4 bytes depending on build flags and 
platform, allocate 1 extra "safety" byte in the network buffer 
for cases when uint3korr() in my_real_read() is called to read
last 3 bytes in the buffer. 
 
It is practically hard to construct a reliable and reasonably 
small test case for this bug as that would require constructing 
input stream such that a certain sequence of bytes in a 
compressed packet happens to be the last 3 bytes of the network 
buffer.