Fix parsing of mysql client commands, especially in relation to
single-line comments when --comments was specified.

This is a little tricky, because we need to allow single-line
comments in the middle of statements, but we don't want to allow
client commands in the middle of statements. So in
comment-preservation mode, we go ahead and send single-line
comments to the server immediately when we encounter them on their
own. 

This is still slightly flawed, in that it does not handle a
single-line comment with leading spaces, followed by a client-side
command when --comment has been enabled. But this isn't a new
problem, and it is quite an edge condition. Fixing it would require
a more extensive overall of how the mysql client parses commands. 

Bug#37671 crash on prepared statement + cursor + geometry + too many open files!
if mysql_execute_command() returns error then free materialized_cursor object.
is_rnd_inited is added to satisfy rnd_end() assertion
(handler may be uninitialized in some cases)


sql/sql_cursor.cc:
  if mysql_execute_command() returns error then free materialized_cursor object.
  is_rnd_inited is added to satisfy rnd_end() assertion
  (handler may be uninitialized in some cases)
sql/sql_select.cc:
  added result check
tests/mysql_client_test.c:
  test case

Removed values with more than 15 significant digits from the test case. Results of 
reading/printing such values using system library functions depend on implementation 
and thus are not portable.

mysql-test/r/type_float.result:
  Removed values with more than 15 significant digits from the test case.
mysql-test/t/type_float.test:
  Removed values with more than 15 significant digits from the test case.

if table has bit fields then uneven bits(if exist) are stored into null bits place.
So we need to copy null bits in case of uneven bit field presence.


mysql-test/r/type_bit.result:
  test result
mysql-test/t/type_bit.test:
  test case
sql/sql_select.cc:
  if table has bit fields then uneven bits(if exist) are stored into null bits place.
  So we need to copy null bits in case of uneven bit field presence.

added ability for TINY[MEDIUM] text fields 
to be converted to greater subtype during
alter if necessary(altered charset)


mysql-test/r/alter_table.result:
  test result
mysql-test/t/alter_table.test:
  test case
sql/sql_table.cc:
  added ability for TINY[MEDIUM] text fields 
  to be converted to greater subtype during
  alter if necessary(altered charset)

the patch manually to another tree. 

the problem: FORMAT func max_length value was calculated incorrectly
the fix: correct calculation of max_length


mysql-test/r/func_str.result:
  test result
mysql-test/t/func_str.test:
  test case
sql/item_strfunc.h:
  the problem: FORMAT func max_length value was calculated incorrectly
  the fix: correct calculation of max_length

show default value for BIT field in printable format


mysql-test/r/type_bit.result:
  Bug#35796 SHOW CREATE TABLE and default value for BIT field
  test result
mysql-test/t/type_bit.test:
  Bug#35796 SHOW CREATE TABLE and default value for BIT field
  test case
sql/item.cc:
  Bug#35796 SHOW CREATE TABLE and default value for BIT field
  issue an error if BIN|HEX deafult value is empty value
  (behaviour like for INT fields)

The reason for the failures was bug #21205 (fixed in 6.0 by dtoa, but still present in 5.0/5.1).

mysql-test/r/type_float.result:
  Modified the failing test case so that bug #21205 does not occur.
mysql-test/t/type_float.test:
  Modified the failing test case so that bug #21205 does not occur.

Altered how we copy data from mysql-test/std_data on Windows to match what we are doing in 5.1 and 6.0

Bug #41173 rpl_packet fails sporadically on pushbuild: query 'DROP TABLE t1' failed


The both issues appeared to be a race between the SQL thread executing CREATE table t1
and the IO thread that is expected to stop at the consequent big size event.
The two events need serialization which is implemented.
The early bug required back-porting a part fixes for bug#38350 exclusively for 5.0 version.



mysql-test/r/rpl_packet.result:
  results changed due to bug#33420, bug#41173.
mysql-test/t/rpl_packet.test:
  adding synchronization for sql and io thread (bug#41173 problem).
  simplifying the output to show only a relevant info (5.0 sole problem bug#33420).

BUG#39325 Server crash inside MYSQL_LOG::purge_first_log halts replicaiton

The patch reverses the order of the purging and updating events for log and relay-log.info/index files respectively.
This solves the problem of having holes caused by crashes happening between updating info/index files and purging logs.

NOTE: This is a combined patch for BUG#38826 and BUG#39325. This patch is based on bugteam tree and takes into account reviewers suggestions.

                    bigint' fails on windows.

Visual Studio does not take into account some x86 hardware limitations
which leads to incorrect results when converting large DOUBLE values
to BIGINT UNSIGNED ones.

Fixed by adding a workaround for double->ulonglong conversion on
Windows.


include/config-win.h:
  Added double2ulonglong(double) function implementing a workaround for
  broken double->ulonglong conversion on Windows/x86.
include/my_global.h:
  Define double2ulonglong() as a simple typecast for anything but
  Windows.
mysql-test/r/type_float.result:
  Added a test case for bug #27483.
mysql-test/t/type_float.test:
  Added a test case for bug #27483.

                  
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.

mysql-test/r/timezone3.result:
  Bug #39920: test case
mysql-test/std_data/Moscow_leap:
  Bug #39920: updated the Moscow time zone to Dr. Olson's tzdata 2008i 
  to accomodate for the 2008 leap second
mysql-test/t/timezone3.test:
  Bug #39920: test case
sql/tztime.cc:
  Bug #39920: adjust leap seconds (:60 or :61) to :59
sql/tztime.h:
  Bug #39920: adjust leap seconds (:60 or :61) to :59

by using and taking out a full path.

mysql-test/r/ctype_filesystem.result:
  Bug #37399: use MYSQL_TEST_DIR rooted test
mysql-test/t/ctype_filesystem-master.opt:
  Bug #37399: use MYSQL_TEST_DIR rooted test
mysql-test/t/ctype_filesystem.test:
  Bug #37399: use MYSQL_TEST_DIR rooted test

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

            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.


mysql-test/r/view.result:
  Added test case for bug #33461.
  Updated test case for bug 28701.
mysql-test/t/view.test:
  Added test case for bug #33461.
  Updated test case for bug 28701.
sql/sql_view.cc:
  Bug #33461: SELECT ... FROM <view> USE INDEX (...) throws
              an error
  
  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.