Optimization of aggregate functions detected constant under max() and evalueted it, but condition in the WHWRE clause (which is always FALSE) was not taken into account

The patch backports two patches from mysql 5.6:
- BUG#12640437: USING SQL_BUFFER_RESULT RESULTS IN A DIFFERENT QUERY OUTPUT
- Bug#12578908: SELECT SQL_BUFFER_RESULT OUTPUTS TOO MANY ROWS WHEN GROUP IS OPTIMIZED AWAY

Original comment:
-----------------
3714 Jorgen Loland	2012-03-01
      BUG#12640437 - USING SQL_BUFFER_RESULT RESULTS IN A DIFFERENT 
                     QUERY OUTPUT
      
      For all but simple grouped queries, temporary tables are used to
      resolve grouping. In these cases, the list of grouping fields is
      stored in the temporary table and grouping is resolved
      there (e.g. by adding a unique constraint on the involved
      fields). Because of this, grouping is already done when the rows
      are read from the temporary table.
      
      In the case where a group clause may be optimized away, grouping
      does not have to be resolved using a temporary table. However, if
      a temporary table is explicitly requested (e.g. because the
      SQL_BUFFER_RESULT hint is used, or the statement is
      INSERT...SELECT), a temporary table is used anyway. In this case,
      the temporary table is created with an empty group list (because
      the group clause was optimized away) and it will therefore not
      create groups. Since the temporary table does not take care of
      grouping, JOIN::group shall not be set to false in 
      make_simple_join(). This was fixed in bug 12578908. 
      
      However, there is an exception where make_simple_join() should
      set JOIN::group to false even if the query uses a temporary table
      that was explicitly requested but is not strictly needed. That
      exception is if the loose index scan access method (explain
      says "Using index for group-by") is used to read into the 
      temporary table. With loose index scan, grouping is resolved 
      by the access method. This is exactly what happens in this bug.

This is a backport of the fix for MySQL bug #13723054 in 5.6.

Original comment:
      The crash is caused by arbitrary memory area owerwriting in case of
      BLOB fields during attempt to copy BLOB field key image into record
      buffer(record buffer is too small to get BLOB key part image).
      note:
      QUICK_GROUP_MIN_MAX_SELECT can not work with BLOB fields
      because it uses record buffer as temporary buffer for key values
      however this case is filtered out by covering_keys() check
      in get_best_group_min_max() as BLOBs always require key length
      modificator in the key declaration and if the key has a BLOB
      then it can not be covered key.
      The fix is to use 'max_used_key_length' key length instead of 0.

Analysis:
Spcifically the crash in this bug was a result of the call to key_copy()
that copied the whole key, inlcuding the BLOB field which is not used
for index access. Copying the blob field overwrote memory as far as the
function parameter 'key_info'. As a result the contents of key_info was
all 0, which resulted in a crash when this key_info was accessed few
lines below in key_cmp().

MDEV-214 lp:967242 Wrong result with JOIN, AND in ON condition, multi-part key, GROUP BY, subquery and OR in WHERE

The problem was in the code (update_const_equal_items()) which marked
index parts constant independently of the place where the equality was used.
In the test suite it marked t2_1.c part constant despite the fact that
it connected by OR with other expression.

Solution is to mark constant only top equalities connected with AND.

Fix is to set  maybe_null  flag for Item_func_last_day.

remove a redundant line in Makefile.am

(for example, one of them sets client capabilities by copying server capabilities)

We cannot fix them - let's tolerate them

This can result in bad deadlocks (e.g loader lock), seen in latest crash reports.

since password characters can contain quotes or spaces.

The proper quoting method for command line arguments used here was  extracted from
http://blogs.msdn.com/b/twistylittlepassagesallalike/archive/2011/04/23/everyone-quotes-arguments-the-wrong-way.aspx

Additionally, mysql_install_db.exe now passes root password to "mysqld.exe --bootstrap"
 in hexadecimal form, to handle potential special chars inside password string literal.

        RB-tree index in the MEMORY table fails if it grews over 4G.
        That happened because the old_allocated variable in hp_rb_write_key()
        had the uint type. Changed with the 'size_t' type to be same as the
        'rb_tree.allocated'.

per-file comments:
  storage/heap/hp_write.c
MDEV-80 Memory engine table full at much less than max_heap_table_size with btree index.
        uint->size_t for the 'old_allocated'.

don't cast implicitly an int to a char, when a boolean value is desired.

The main problem was a bug in CSV where it provided wrong statistics (it claimed the table was empty when it wasn't)
I also fixed wrong freeing of blob's in the CSV handler. (Any call to handler::read_first_row() on a CSV table with blobs would fail)



mysql-test/r/csv.result:
  Added new test case
mysql-test/r/partition_innodb.result:
  Updated test results after fixing bug with impossible partitions and const tables
mysql-test/t/csv.test:
  Added new test case
sql/sql_select.cc:
  Cleaned up code for handling of partitions.
  Fixed also a bug where we didn't threat a table with impossible partitions as a const table.
storage/csv/ha_tina.cc:
  Allocate blobroot onces.

Fixed that repair removes the 'table is moved' mark.

mysql-test/suite/maria/r/maria-autozerofill.result:
  Test case for lp:967914
mysql-test/suite/maria/t/maria-autozerofill.test:
  Test case for lp:967914
storage/maria/ha_maria.cc:
  Fixed that repair removes the 'table is moved' mark.

The issue was that check/optimize/anaylze did not zerofill the table before they started to work on it.
Added one more element to not often used function handler::auto_repair() to allow handler to decide when to auto repair.


mysql-test/suite/maria/r/maria-autozerofill.result:
  Test case for lp:944422
mysql-test/suite/maria/t/maria-autozerofill.test:
  Test case for lp:944422
sql/ha_partition.cc:
  Added argument to auto_repair()
sql/ha_partition.h:
  Added argument to auto_repair()
sql/handler.h:
  Added argument to auto_repair()
sql/table.cc:
  Let auto_repair() decide which errors to trigger auto-repair
storage/archive/ha_archive.h:
  Added argument to auto_repair()
storage/csv/ha_tina.h:
  Added argument to auto_repair()
storage/maria/ha_maria.cc:
  Give better error & warning messages for auto-repaired tables.
storage/maria/ha_maria.h:
  Added argument to auto_repair()
  Always auto-repair in case of moved table.
storage/maria/ma_open.c:
  Remove special handling of HA_ERR_OLD_FILE (this is now handled in auto_repair())
storage/myisam/ha_myisam.h:
  Added argument to auto_repair()

lp:933959 Assertion `0' failed in net_end_statement(THD*) on concurrent SELECT FROM I_S.INNODB_SYS_INDEXES and ALTER TABLE

Workaround: report a generic error if an I_S plugin failed silently.

use vsnprintf()
use write() on windows, not WriteFile or fwrite()
localtime_r is still a problem