the mysql test suite.

Tests removed:
1. innodb_trx_weight.test
2. innodb_bug35220.test

Include files removed:
1. have_innodb.inc
2. ctype_innodb_like.inc
3. innodb_trx_weight.inc

Also add the missing opt file for the test innodb-use-sys-malloc.test

option doesn't affect innodb_plugin.

Currently it works as following:
* configure without relevant options producing two dynamic plugins
* configure --with-plugin-innodb (or legacy --with-innodb) producing
  static standard InnoDB
* configure --without-plugin-innodb (or legacy --without-innodb)
  disabling standard InnoDB
* configure --with-plugin-innodb_plugin producing dynamic innodb_plugin
* configure --without-plugin-innodb_plugin disabling innodb_plugin

Created a test suite 'innodb' under mysql-test/suite/innodb for the innodb plugin tests.
test suite 'innodb' has tests only which are not under any other mysql-test suites.

Total 14 testcases are added to the test suite.

Note: the patches in storage/innodb_plugin/mysql-test/patches are not applied yet

change tree name to 'mysql-5.1-innodb_plugin'

Let the user specify 'auto' for parallel value
Also set --parallel=auto in default.push so we can get this tested.

Added calls to mtr_report_stats() also after timeout or too many failures

The Innodb plugin 1.0.4 can be installed dynamically using the 'INSTALL PLUGIN' syntax

If mysqld is already statically linked with the inbuilt innodb, it is not possible to 
install the innodb plugin 1.0.4 dynamically. Doing so would throw this error - Function
'innodb' already exists.

Adding "w# " before the test result
Also enable --parallel=2 so this can be tested.

On 64-bit Windows: querying MERGE table with keys may cause
server crash.The problem is generic and may affect any statement
accessing MERGE table cardinality values.
When MERGE engine was copying cardinality statistics, it was
using incorrect size of element in cardinality statistics array
(sizeof(ptr)==8 instead of sizeof(ulong)==4), causing access
of memory beyond of the allocated bounds.

Protected '' in connect command with ""

The fix is to allow myisamchk to use >4G key_buffer_size on win64

Incorrection assumption about delimiter character in connection command

doesn't find 'logger'

Due to a variable quoting mistake, the $PATH environment
variable isn't parsed correctly when searching for the
existence of the desired executable(s) (logger in this 
case).

This patch removes the quotes.

check_command_args() always looks for the first , (or whatever)
Extended check_command_args() to let arguments be quoted
Added test in mysqltest.test

The problem is that the server failed to follow the rule that
every X509 object retrieved using SSL_get_peer_certificate()
must be explicitly freed by X509_free(). This caused a memory
leak for builds linked against OpenSSL where the X509 object
is reference counted -- improper counting will prevent the
object from being destroyed once the session containing the
peer certificate is freed.

The solution is to explicitly free every X509 object used.

HAVING
            
When calculating GROUP BY the server caches some expressions. It does
that by allocating a string slot (Item_copy_string) and assigning the 
value of the expression to it. This effectively means that the result
type of the expression can be changed from whatever it was to a string.
As this substitution takes place after the compile-time result type 
calculation for IN but before the run-time type calculations, 
it causes the type calculations in the IN function done at run time 
to get unexpected results different from what was prepared at compile time.
                  
In the CASE ... WHEN ... THEN ... statement there was a similar problem
and it was solved by artificially adding a STRING argument to the set of 
types of the IN/CASE arguments at compile time, so if any of the 
arguments of the CASE function changes its type to a string it will 
still be covered by the information prepared at compile time.

stop/start slave
      
When stopping and restarting the slave while it is replicating
temporary tables, the server would crash or raise an assertion
failure. This was due to the fact that although temporary tables are
saved between slave threads restart, the reference to the thread in
use (table->in_use) was not being properly updated when the restart
happened (it would still reference the old/invalid thread instead of
the new one).
      
This patch addresses this issue by resetting the reference to the new
slave thread on slave thread restart.

Created new .test file - mysqldump_restore that does test restore from mysqldump
output for a limited number of basic cases.
Create new .inc file - mysqldump.inc - renames original table and uses mysqldump
output to recreate the table, then uses diff_tables.inc to compare the two tables.
Backported include/diff_tables.inc to facilitate this testing.
New patch incorporating review feedback prior to push.

mysqldump.test - removed redundant call to include/have_log_bin.inc (was used twice in the test!)

            assertion .\filesort.cc, line 797

Minor fix to test case (embedded server failure).

            assertion .\filesort.cc, line 797

A query with the "ORDER BY @@some_system_variable" clause,
where @@some_system_variable is NULL, causes assertion
failure in the filesort procedures.

The reason of the failure is in the value of
Item_func_get_system_var::maybe_null: it was unconditionally
set to false even if the value of a variable was NULL.