Bug#11745920/Bug#21287: "SSL connection error" is not helpful! (ssl-verify-server-cert=true vs localhos)

SSL errors on client and now more specific to aid end-user
with debugging. Also restructures error handling for
compliance with SSL docs.

include/violite.h:
  new_VioSSLConnectorFd/sslaccept/sslconnect return more elaborate status
libmysql/errmsg.c:
  SSL errors now extended, more specific
mysql-test/r/openssl_1.result:
  SSL errors now extended, more specific
sql-common/client.c:
  Do more detailed error reporting for setup, connect, and
  server cert verifying phases.
sql/sql_acl.cc:
  sslaccept() signature has changed
vio/viossl.c:
  Save the error code and return it to callers of sslaccept
  and sslconnect.
vio/viosslfactories.c:
  new_VioSSLConnectorFd(): return error code to caller

There are two problems:
1. There is a missing check for 'year' parameter(year can not be greater than 9999) in
   makedate function. fix: added check that year can not be greater than 9999.
2. There is a missing check for zero date in from_days() function.
   fix: added zero date check into Item_func_from_days::get_date()
   function.


mysql-test/r/func_time.result:
  test case
mysql-test/t/func_time.test:
  test case
sql/item_timefunc.cc:
  --added check that year can not be greater than 9999 for makedate() function
  --added zero date check into Item_func_from_days::get_date() function

- Added an alterantive search path for WiX components
- Added a custom welcome dialog to include the copyright line (Bug#59805 and Bug#59512)
- Excluded some binaries to make package smaller, in effect makig the
  "essentials" package obsolete
- Added a bit more error checking when running the WiX tools

WiX XML changes done by Johannes Taxacher

notifying PB2 the test fails through mysql-test/collections/default.experimental.

FREED IN FLUSH_READ_LOCK (VALGRIND WARNING).

The problem was that under some circustances the memory allocated
for Query_tables_list::sroutines was not freed properly.
The cause of this problem was the absence of
LEX::restore_backup_query_tables_list() call in one of the branches
in mysql_table_grant() function.

      
Impementing Test Review Comment.
      
Bug test scenario:      
SELECT is not returning result set for "equal" (=) and "NULL safe equal
operator"  (<=>) on BIT data type. Extending this scenario for all data types

Before this fix, a thread instrumented for the performance schema,
that would perform file io operations, could crash inside the LF_HASH
implementation, in cases when my_thread_init is not called.

The crash itself has not been reported in 5.5 but similar crashes have
been found in 5.6-based development branches, using LF_HASH for
more instrumentation.

The possibility of a crash in 5.5 is confirmed by code analysis.

The problem is that, when my_thread_init() is not called,
which can happen for threads in storage engines or thirs party code,
my_thread_var is NULL.

Using my_thread_var->stacks_ends_here in mysys/lf_alloc-pin.c is unsafe.

Given that my_thread_var is used:
- only for stacks_ends_here
- only on platform with HAVE_ALLOCA
- only when there is enough room on the stack
and given that the LF_HASH implementation has a fallback
algorythm implemented already when using alloca is not possible,
using my_thread_var->stacks_ends_here is in fact not a strict requirement,
and can be relaxed.

The fix is to:
- test explicitly if my_thread_var is NULL, to account for cases
  when my_thread_init() is not used by the calling thread.
- not use alloca in this case, and rely on the fall back code already in place.
  so that the LF_HASH can be supported even without my_thread_init().

The implementation of mysys/lf_alloc-pin.c has been fixed to support this new usage.
The units tests in unittest/mysys/lf-t.c have been adjusted accordingly.

This patch inserts an 'ENABLE_GCOV' option for enabling gcov compilation
on Linux machines. It modifies the CMakeLists.txt setting this option
to 'OFF' by default.

Note: The option requires a debug build. For example, 
      -DCMAKE_BUILD_TYPE:string="Debug" 

This assert could be triggered during two phase commit if binary
log was used as transaction coordinator log. The triggered assert
checks that the same number of transaction IDs are processed in
the prepare and commit phases.

The reason it was triggered, was that the transaction consisted
of an INSERT/UPDATE IGNORE that had an ignorable error. Since it
had an error, no row log events were made and therefore
prepared_xids was 0. However, since it was an IGNORE statement,
the statement started a read/write statement transaction, committed
it and completed successfully.

This patch fixes the problem by adjusting the assert to take
this possibility into account.

Test case added to binlog.binlog_innodb_row.test.

If LOAD DATA INFILE featured a SET clause, the name=value pairs
would be regenerated using item::print. Unfortunately, that code
is mostly optimized for EXPLAIN EXTENDED output and such, and can
not be relied on to return valid SQL.

We now name each value its original, user-supplied form and use
that to create LOAD DATA INFILE statements for statement-based
replication.

mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result:
  minor change in syntactic sugar
mysql-test/suite/rpl/r/rpl_loaddatalocal.result:
  add test case
mysql-test/suite/rpl/t/rpl_loaddatalocal.test:
  add test case
sql/sql_load.cc:
  Do not try to item::print values in LOAD DATA INFILE's
  SET clause; they might not even be valid SQL at this
  point. Use our saved version instead.
sql/sql_yacc.yy:
  If LOAD DATA INFILE has SET name=val clauses, tag the
  individual val-parts with the user's version so we can
  later replicate that, rather than the smashed pieces
  we'd get from item::print once the optimizer's through
  with our poor values.

Automerged bzr bundle from bug report into latest mysql-5.5.

increase the version number by two

and innodb

The 5.5 version of the patch.

The server doesn't restrict the data that can be inserted into integer columns 
with explicitly specified length that's smaller than what the type can handle,
e.g. 1234 can be inserted into an INT(2) column just fine.
Thus, when calcualting the maximum width of expressions involving such 
restricted integer columns we need to use the implicit maximum width of 
the field instead of the explicitly speficied one.
Fixed the server to use the implicit maximum in such cases and made sure 
the implicit maximum is addjusted the same way as the explicit one wrt
signedness.

Fixed several test case results (ctype_*.result, metadata.result and 
type_ranges.result) to reflect the extended column widths.

Added a regression test case in distinct.test.

Note : this is the behavior preserving fix that makes 5.5 behave as 5.1 and 
earlier. In the mysql trunk we'll add a insert time check for the explict 
maximum size.

 - add support for choosing the engine of test
    table(t1) with $engine_type
 - add primary key to the test table(t1) to support
   replication of BLOB/TEXT (also with ENGINE=ndb)
 - change the suppression since the warning printed to error log
  now says "Column 1"