(Backport to 5.3)
(variant #2, with fixed coding style)
- Make Mrr_ordered_index_reader::resume_read() restore index position 
  only if it was saved before with Mrr_ordered_index_reader::interrupt_read().

- TABLE::create_key_part_by_field() should not set PART_KEY_FLAG in field->flags
  = The reason is that it is used by hash join code which calls it to create a hash
    table lookup structure. It doesn't create a real index.
  = Another caller of the function is TABLE::add_tmp_key(). Made it to set the flag itself.

- The differences in join_cache.result could also be observed before this patch: one
  could put "FLUSH TABLES" before the queries and get exactly the same difference.

Avoided exponential recursive calls of JOIN_CACHE::join_records() in the case
of non-nested outer joins.
A different solution is required to resolve this performance problem for
nested outer joins.

Do not define a look-up key for a temporary table if its length
exceeds the maximum length of such keys. 

MDEV-6302 Wrong result set when using GROUP BY FROM_UNIXTIME(...)+0
Fixed.

KILL USER should ignore system threads where sctx->user=sctx->host=NULL

Item_func_min_max::get_date() did not clear ltime->year when returning a TIME value.

"have_warnings" was set to an uninialized value when converting
a negative number to datetime.

MDEV-6099 Bad results for DATE_ADD(.., INTERVAL 2000000000000000000.0 SECOND)
MDEV-6097 Inconsistent results for CAST(int,decimal,double AS DATETIME)
MDEV-6100 No warning on CAST(9000000 AS TIME)

mysql_derived_merge() made correctly working with views.

It is triple bug with one test suite:
1. Incorrect outer table detection
2. Incorrect leaf table processing for multi-update (should be full like for usual updates and inserts)
3. ON condition fix_fields() fould be called for all tables of the query.

MariaDB-specific result replacement

A typo in include file caused the timeout counter to be 10x less than
expected. It was fixed in 5.5.20+ along with a bigger change, now also
fixing in 5.1-5.3.

MDEV-6134 SUBSTRING_INDEX returns wrong result for 8bit character sets when delimiter is not found

Recording the forgotten test results.

Both bugs are caused by the same problem: the function optimize_cond() should
update the value of *cond_equal rather than the value of join->cond_equal,
because it is called not only for the WHERE condition, but for the HAVING
condition as well.

Add test case.

Revert the old patch revid:monty@askmonty.org-20100325133339-7mkel6valai0b4lb

This patch caused the InnoDB part of the transaction to not be marked
read-write in some cases, which messes up XA commit (and likely other
stuff as well).

MDEV-5783 Assertion `0' failed in make_sortkey(SORTPARAM*, uchar*, uchar*) on ORDER BY HEX( UNCOMPRESSED_LENGTH( pk ) )

MDEV-5446: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' fails on EXPLAIN EXTENDED with VALUES function

field_index should be set correctly for null field created by Item_insert_value::fix_fields().

(as it's done in 10.0)

- With big_tables=ON, materialized table will use Aria (or MyISAM) SE, which
  allows prefix key reads. However, the temp.table has rec_per_key=NULL which
  causes the optimizer to crash when attempting to read index statistics for a 
  prefix index read.
- Fixed by providing a rec_per_key array with zeros (i.e. "no statistics data")