- Let JTBM optimization code handle the case where the subquery is degenerate and doesn't have a 
  join query plan. Regular materialization would fall back to IN->EXISTS for such cases. Semi-Join
  materialization does not have such option, instead we introduce and use "constant JTBM join tabs".

A memory overwrite in the function test_if_skip_sort_order()
could cause a crash for some queries with subqueries.

- Do a "more thorough" cleanup of SJ-Materialization join tab in JOIN_TAB::cleanup. The bug
  was due to the fact that JOIN_TAB::cleanup() may be called multiple times for the same tab
  if the join has grouping.

Updated version number in configure

sql/set_var.cc:
  Moved query_cache_strip_comments from EMBEDDED_LIBRARY to HAVE_QUERY_CACHE

mysql-test/suite/maria/r/maria-recovery3.result:
  Added test case for recovery bug
mysql-test/suite/maria/t/maria-recovery3.test:
  Added test case for recovery bug
storage/maria/ha_maria.cc:
  Don't print query twice to log
storage/maria/ma_delete.c:
  More DBUG_PRINT
storage/maria/ma_key_recover.c:
  Added new asserts to detect errors earlier
storage/maria/ma_recovery.c:
  Update all states when moving a non-transactional file to transactional. This fixes lp:887051

- Changed storage to be 2 bytes instead of sizeof(size_t) (simple optimization)
- Fixed bug when using query_cache_strip_comments and query that started with '('
- Fixed DBUG_PRINT() that used wrong (not initialized) variables.


mysql-test/mysql-test-run.pl:
  Added some space to make output more readable.
mysql-test/r/query_cache.result:
  Updated test results
mysql-test/t/query_cache.test:
  Added test with query_cache_strip_comments
sql/mysql_priv.h:
  Added QUERY_CACHE_DB_LENGTH_SIZE
sql/sql_cache.cc:
  Fixed bug when using query_cache_strip_comments and query that started with '('
  Store db length in 2 characters instead of size_t.
  Get db length from correct position (earlier we had an error when query started with ' ')
  Fixed DBUG_PRINT() that used wrong (not initialized) variables.

The range optimizer incorrectly chose a loose scan for group by
when there is a correlated WHERE condition. This range access
method cannot be executed for correlated conditions also with the
"range checked for each record" because generally the range access
method can change for each outer record. Loose scan destructively
changes the query plan and removes the GROUP operation, which will
result in wrong query plans if another range access is chosen
dynamically.

The cause of the reported assertion failure was a division of a double value by 0. 

Removed previous patch of this problem.

If the duplicate elimination strategy is used for a semi-join and potentially
one of the block-based join algorithms can be employed to join the inner
tables of the semi-join then sorting of the head (first non-constant) table
for a query with ORDER BY / GROUP BY cannot be used.

- Instead of supressing all errors, only suppress safe ones like:
ER_DUP_KEY, ER_BAD_NULL_ERROR, ER_SUBQUERY_NO_1_ROW, ER_ROW_IS_REFERENCED_2

no_error handling for select (used by INSERT ... SELECT) still needs to be fixed, but I will do that in a separate commit

The function setup_sj_materialization_part1() forgot to set the value
of TABLE::map for any materialized IN subquery. 
This could lead to wrong results for queries with subqueries that were
converted to queries with semijoins.

        Coinciding nodes can appear as a result of DOUBLE inaccuracy.
        We should test that before we start the loop.

        Also the spatial relations can be calculated faster if we check
        MBR relations first. And we do have the shape's MBR-s now.

per-file comments:
  sql/gcalc_slicescan.cc
        set_extent() method added.
bug #901655 ST_BUFFER asserts with a coplicated shape.
  sql/gcalc_slicescan.h
        set_extent() method declared.
bug #901655 ST_BUFFER asserts with a coplicated shape.
  sql/gcalc_tools.cc
bug #901655 ST_BUFFER asserts with a coplicated shape.
        checks for equal nodes added.
  sql/item_geofunc.cc
bug #901655 ST_BUFFER asserts with a coplicated shape.
        MBR for the shapes calculated, and MBR checks added before we
        start the heavy calculations.
  sql/spatial.h
bug #901655 ST_BUFFER asserts with a coplicated shape.
        MBR::buffer() method implemented.

Analysis:
The class member QUICK_GROUP_MIN_MAX_SELECT::seen_first_key
was not reset between subquery re-executions. Thus each
subsequent execution continued from the group that was
reached by the previous subquery execution. As a result
loose scan reached end of file much earlier, and returned
empty result where it shouldn't.

Solution:
Reset seen_first_key before each re-execution of the
loose scan.

- if we're considering FirstMatch access with one inner table, and 
  @@optimizer_switch has semijoin_with_cache flag, calculate costs
  as if we used join cache (because we will be able to do so)

- opt_sum_query() should not assume that join tables from sj-materialization
  have known numbers of rows.

- Part2: safety and code cleanup

The execution plan cannot use sorting on the first table from the
sequence of the joined tables if it plans to employ the block-based
hash join algorithm.

- Part 1 of the fix: for semi-join merged subqueries, calling child_join->optimize() until we're done with all
  PS-lifetime optimizations in the parent.

The optimizer must ignore any possible hash join key when looking for the 
query execution plan with join_cache_level set to 0.  

- Make create_tmp_table() set KEY_PART_INFO attributes for the keys it creates.
  This wasn't needed before but is needed now, when temp. tables that are 
  results of SJ-Materialization are being used for joins.
  This particular bug depended on HA_VAR_LENGTH_PART being set,
  but also added code to set HA_BLOB_PART and HA_NULL_PART when appropriate.

KEYUSE elements for a possible hash join key are not sorted by field
numbers of the second table T of the hash join operation. Besides
some of these KEYUSE elements cannot be used to build any key as their
key expressions depend on the tables that are planned to be accessed
after the table T. 
The code before the patch did not take this into account and, as a result,
execition of a query the employing block-based hash join algorithm could
cause a crash or return a wrong result set.