1. Field_newdate::get_date should refuse to return a date with zeros when
   TIME_NO_ZERO_IN_DATE is set, not when TIME_FUZZY_DATE is unset
2. Item_func_to_days and Item_date_add_interval can only work with valid dates,
   no zeros allowed.

fix Item_func_add_time::get_date() to generate valid dates.
Move the validity check inside get_date_from_daynr()
instead of relying on callers
(5 that had it, and 2 that did not, but should've)

storage engine in HA_MRR_NO_ASSOCIATION mode.
(there is no testcase because we don't ship any such engines currently)

force -fno-strict-aliasing for oqgraph

The problem was that was_null and null_value variables was reset in each reexecution of IN subquery, but engine rerun only for non-constant subqueries.

Fixed checking constant in Item_equal sort.
Fix constant reporting in Item_subselect.

Various places in the server replication code was incorrectly quoting
strings, which could lead to incorrect SQL on the slave/mysqlbinlog.

Item::get_date() should return 1 unless the value is a valid date.

two tests still fail:
  main.innodb_icp and main.range_vs_index_merge_innodb
  call records_in_range() with both range ends being open
  (which triggers an assert)

increase xtradb verson from 13.0 to 13.01

The bug could caused a crash when the server executed a query with
ORDER by and sort_buffer_size was set to a small enough number.
It happened because the small sort buffer did not allow to allocate
all merge buffers in it.
Made sure that the allocated sort buffer would be big enough
to contain all possible merge buffers.  

Following reasons caused mismatches:
  - different handling of invalid values;
  - different CAST results with fractional seconds;
  - microseconds support in MariaDB;
  - different algorithm of comparing temporal values;
  - differences in error and warning texts and codes;
  - different approach to truncating datetime values to time;
  - additional collations;
  - different record order for queries without ORDER BY;
  - MySQL bug#66034.
More details in MDEV-369 comments.

Following reasons caused mismatches:
  - different handling of invalid values;
  - different CAST results with fractional seconds;
  - microseconds support in MariaDB;
  - different algorithm of comparing temporal values;
  - differences in error and warning texts and codes;
  - different approach to truncating datetime values to time;
  - additional collations;
  - different record order for queries without ORDER BY;
  - MySQL bug#66034.
More details in MDEV-369 comments.

- index_merge/intersection is unable to work on GIS indexes, because:
  1. index scans have no Rowid-Ordered-Retrieval property
  2. When one does an index-only read over a GIS index, they do not 
     get the index tuple, because index only contains bounding box of the geometry.
     This is why key_copy() call crashed.
This patch fixes #1, which makes the problem go away. Theoretically, it would 
be nice to check #2, too, but SE API semantics is not sufficiently precise to do it.

No commit message

Problem:
=======
The return value from my_b_write is ignored by: `my_b_write_quoted',
`my_b_write_bit',`Query_log_event::print_query_header'

Most callers of `my_b_printf' ignore the return value. `log_event.cc' 
has many calls to it. 

Analysis:
========
`my_b_write' is used to write data into a file. If the write fails it
sets appropriate error number and error message through my_error()
function call and sets the IO_CACHE::error == -1.
`my_b_printf' function is also used to write data into a file, it
internally invokes my_b_write to do the write operation. Upon
success it returns number of characters written to file and on error
it returns -1 and sets the error through my_error() and also sets
IO_CACHE::error == -1.  Most of the event specific print functions
for example `Create_file_log_event::print', `Execute_load_log_event::print'
etc are the ones which make several calls to the above two functions and
they do not check for the return value after the 'print' call. All the above 
mentioned abuse cases deal with the client side.

Fix:
===
As part of bug fix a check for IO_CACHE::error == -1 has been added at 
a very high level after the call to the 'print' function.  There are 
few more places where the return value of "my_b_write" is ignored
those are mentioned below.

+++ mysys/mf_iocache2.c    2012-06-04 07:03:15 +0000
@@ -430,7 +430,8 @@
           memset(buffz, '0', minimum_width - length2);
         else
           memset(buffz, ' ', minimum_width - length2);
-        my_b_write(info, buffz, minimum_width - length2);

+++ sql/log.cc	2012-06-08 09:04:46 +0000
@@ -2388,7 +2388,12 @@
     {
       end= strxmov(buff, "# administrator command: ", NullS);
       buff_len= (ulong) (end - buff);
-      my_b_write(&log_file, (uchar*) buff, buff_len);

At these places appropriate return value handlers have been added.

client/mysqlbinlog.cc:
  check for IO_CACHE::error == -1 has been added after the call to
  the event specific print functions
mysys/mf_iocache2.c:
  Added handler to check the written value of `my_b_write'
sql/log.cc:
  Added handler to check the written value of `my_b_write'
sql/log_event.cc:
  Added error simulation statements in `Create_file_log_event::print`
  and `Execute_load_query_log_event::print'
sql/rpl_utility.h:
  Removed the extra ';'