BUG#671361: virtual int Mrr_ordered_index_reader::refill_buffer(): Assertion `!know_key_tuple_params
- Make sure we have enough space for both rowids and keys.

- Disable identical key handling optimization when
  IndexConditionPushdown is used

- Code cleanup
- Always propagate the error code we got from storage engine all the way up

- Update test results
- Handle the case where MRR implementation doesn't get any key tuples at all

- A certain problem with NULLs filtering was solved in two different 
  ways. Use MWL#128's approach (it's more generic) and rollback DS-MRR's.

- Merge into 5.3-main

Prohibited to use hash join algorithm BNLH if join attributes
need non-binary collations. It has to be done because BNLH does
not support join for such attributes yet.
Later this limitations will be lifted.

Changed default collations for the schemes of some test cases
to preserve the old execution plans.

The bug could cause wrong results for queries over Maria tables when
index condition pushdown was used.

- Correct buffer re-allocation

- buildbot test failure fixes: don't try to get more records from SimpleIndexReader
  if we've already got EOF for it.

- address the review feedback (class/var renames)
- fix wrong test result (bug in buffer refill logic)

The set of Ordered keys of a rowid merge engine is dense. Thus when
we decide not to create a key for a column that has only NULLs, this
column shouldn't be counted.

Notice that the caller has already precomputed the correct total
number of keys that should be created.

Post-review fix - avoid re-evaluation of the having clause
when it evaluates to true.

sql/sql_expression_cache.cc:
  Type of the variable fixed.
sql/sql_expression_cache.h:
  Type of the variable fixed.

The cause for this bug is that MariaDB 5.3 still processes derived tables
(subqueries in the FROM clause) by fully executing them during the parse
phase. This will be remedied by MWL#106 once merged into the main 5.3.

The assert statement is triggered when MATERIALIZATION is ON for EXPLAIN
EXTENDED for derived tables with an IN subquery as follows:
- mysql_parse calls JOIN::exec for the derived table as if it is regular
  execution (not explain).
- When materialization is ON, this call goes all the way to
  subselect_hash_sj_engine::exec, which creates a partial match engine
  because of NULL presence.
- In order to proceed with normal execution, the hash_sj engine substitutes
  itself with the created partial match engine.
- After the parse phase it turns out that this execution was part of
  EXPLAIN EXTENDED, which in turn calls
  Item_cond::print -> ... -> Item_subselect::print,
  which calls engine->print().
  Since subselect_hash_sj_engine::exec substituted the current
  Item_subselect engine with a  partial match engine, eventually we call
  its ::print() method. However the partial match engines are designed only
  for execution, hence there is no implementation of this print() method.

The fix temporarily removes the assert, until this code is merged with
MWL#106.

The bug was a result of missing logic to handle the case
when there are 'expensive' predicates that are not evaluated
during constant table optimization. Such is the case for
the IN predicate, which is considered expensive if it is
computed via materialization. In general this bug can be
triggered with any expensive predicate instead of IN.

When FALSE constant predicates are not evaluated during constant
optimization, the execution path changes so that instead of
setting JOIN::zero_result_cause after make_join_select, and
exiting JOIN::exec via the call to return_zero_rows(), execution
ends in JOIN::exec in the branch:
if (join->tables == join->const_tables)
{
  ...
  else if (join->send_row_on_empty_set())
     ...
     rc= join->result->send_data(*columns_list);
}
Unlike return_zero_rows(), this branch didn't evaluate the
having clause of the query.

The patch adds a call to evaluate the HAVING clause of a query even
when all tables are constant, because even for an empty result set
some aggregate functions may produce a NULL value.

When join buffers are employed no index scan for the first
table with grouping columns can be used.



mysql-test/r/join_cache.result:
  Added a test case for bug #664508.
  Sorted results for some other test cases.
mysql-test/t/join_cache.test:
  Added a test case for bug #664508.
  Sorted results for some other test cases.

bugfix: engine defined table options were not showing up in INFORMATION_SCHEMA.TABLES.CREATE_OPTIONS

After the patch for bug 663840 had been applied the test case for
bug 663818 triggered the assert introduced by this patch.
It happened because the the patch turned out to be incomplete:
the space needed for a key entry must be taken into account
for the record written into the buffer, and, for the next record
as well, when figuring out whether the record being written is
the last for the buffer or not.