Fixed the case when a polygon contains a single-point ring.

Backport to 5.3:
- Don't call index_reader->interrupt_read() if the
  index reader has returned all rows that matched its keys.

(Backport to 5.3)
(Attempt #2)
- Don't attempt to use BKA for materialized derived tables. The 
  table is neither filled nor fully opened yet, so attempt to 
  call handler->multi_range_read_info() causes crash.

(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.

After constant row substitution the WHERE condition may be simplified and its multiple equality
may be changed. In this case the references to these multiple equalities from the COND_EQUAL
objects associated with ON expressions must be updated.
Also we have to take into account that this simplification may lead to equalities of the form
field=const that are mutually exclusive with some of the equalities in ON expressions. 

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)