Cleanup: remove TIME_FUZZY_DATE.

Introduce TIME_FUZZY_DATES which means "very fuzzy, the resulting
value is only used for comparison. It can be invalid date, fine, as long as it can be
compared".

Updated many tests results (they're better now).

modified:
  sql/time.cc

Item_func_min_max::get_date() did not check the
returned value against the fuzzy_date flags, so
it could return a bad value to the caller that
expects a good date (e.h. CONVERT_TZ).


modified:
  mysql-test/r/type_date.result
  mysql-test/r/type_datetime.result
  mysql-test/r/type_time.result
  mysql-test/t/type_date.test
  mysql-test/t/type_datetime.test
  mysql-test/t/type_time.test
  sql/item_func.cc
  sql/item_timefunc.cc
  sql/mysql_priv.h
  sql/time.cc

modified:
  mysql-test/r/func_time.result
  mysql-test/t/func_time.test
  sql/item_timefunc.cc
  sql/mysql_priv.h

modified:
  mysql-test/r/ps_2myisam.result
  mysql-test/r/ps_3innodb.result
  mysql-test/r/ps_4heap.result
  mysql-test/r/ps_5merge.result
  mysql-test/r/type_datetime_hires.result
  mysql-test/suite/maria/r/ps_maria.result
  mysql-test/t/type_datetime_hires.test
  sql/item_timefunc.h

mysql_derived_merge_for_insert() should not be called for views or derived tables which are not put (directly or via other views) in main SELECT_LEX "join list".

MDEV-4280: Assertion `empty_size == empty_size_on_page' failure in ma_blockrec.c or ER_NOT_KEYFILE on query with DISTINCT and GROUP BY
This could happen when using Aria for internal temporary files (default case) and using DISTINCT.
_ma_scan_restore_block_record() didn't work correctly if there was rows inserted, updated or deleted on the handler
between calls to _ma_scan_remember_block_record() and _ma_scan_restore_block_record().
The effect was that some DISTINCT queries that used remove_dup_with_compare() could fail.

.bzrignore:
  Ignore sql_yacc.hh
mysql-test/suite/maria/r/distinct.result:
  Test case for MDEV-4280
mysql-test/suite/maria/t/distinct.test:
  Test case for MDEV-4280
mysql-test/t/mysql.test:
  Fixed test suite (we could get error -1 in some cases)
sql/sql_select.cc:
  Break loop if restart_rnd_next() gives an error
storage/maria/ha_maria.cc:
  scan_restore_pos() can return disk fault error.
storage/maria/ma_blockrec.c:
  _ma_scan_remember_block_record() did incorrectly update scan.dir instead of scan_save.dir .
  _ma_scan_restore_block_record() didn't work correctly if there was rows inserted,updated or deleted on the handler
  between calls to _ma_scan_remember_block_record() and _ma_scan_restore_block_record().
  Fixed by adding counters for row changes and reading the current scan page if changes had been made.
storage/maria/ma_blockrec.h:
  scan_restore_pos() can return disk fault error.
storage/maria/ma_delete.c:
  Increment row_changes
storage/maria/ma_scan.c:
  scan_restore_pos() can return disk fault error.
storage/maria/ma_update.c:
  Increment row_changes
storage/maria/ma_write.c:
  Increment row_changes
storage/maria/maria_def.h:
  scan_restore_pos() can return disk fault error.

avoid divison by zero

Fix agregate function resolution in derived tables (no name resolution over a derived table border)

- Rollback an earlier patch (was pushed into 5.3 instead of 5.5)

When iterating over a list of conditions using List_iterator
the function remove_eq_conds should skip all predicates that
replace a condition from the list. Otherwise it can come to
an infinite recursion. 

<non-nullable datatime field> IS NULL in outer joins with
that in inner joins.
Previously such condition was transformed into the condition
<non-nullable datatime field> = 0 unless the field belonged
to an inner table of an outer join. In this case the predicate
was interpreted as for any other field.
Now if the field in the predicate <non-nullable datatime field> IS NULL
belongs to an inner table of an outer join the predicate is 
transformed into the disjunction
<non-nullable datatime field> = 0 OR <non-nullable datatime field> IS NULL.
This is fully compatible with the semantics of such predicates in 5.5.

This bug was the result of incompleteness of the patch for bug mdev-4177.
When an OR condition is simplified to a single conjunct it is merged
into the embedding AND condition. Multiple equalities are also merged,
and any field item involved in those equality should acquire a pointer
to a the multiple equality formed by this merge.

Removed "optimization" which caused preoblems on second execution of PS with string parameter in LIMIT clause.

Fixed test_bug43560 to be able to skipp it if connection is UNIX socket.

fixes for gcc 4.8 - compilation warnings and -fsanitize=address

fixes for gcc 4.8 -fsanitize=address

fulltext search was initialized for all MATCH ... AGAINST items
at the end of the JOIN::optimize(). But since 5.3 derived tables
are initialized lazily on first use, very late in the sub_select().

Skip Item_func_match::init_search initialization if the corresponding
table isn't open yet; repeat fulltext initialization for all
not-yet-initialized MATCH ... AGAINST items after creating derived tables.

currently get_mm_tree skipped the evaluation of this constant
and icorrectly proceeded. The correct behavior is to return a
NULL subtree, according to the IF branch being fixed - when it
evaluates the constant it returns a value, and doesn't continue
further.

update 5.1 to replicate from 10.0 and
to show the server version (as of 10.0) correctly

sql-common/client.c:
  mdev:4088
sql/slave.cc:
  use the version number, not just the first character of the version string
  (we want 10 > 4 not "10" < "4").

- Let index_merge allocate table handlers on quick select's MEM_ROOT,
  not on statement's MEM_ROOT. 
  This is crucial for big "range checked for each record" queries, where 
  index_merge can be created and deleted many times during query exection. 
  We should not make O(#rows) allocations on statement's MEM_ROOT.

- When converting a subquery to a semi-join, propagate OPTION_SCHEMA_TABLE.

          The get_mbr() method shouldn't return the error, rather an invalid MBR
          in this case.

Fixed printing column_get finction.

In some cases, when using views the optimizer incorrectly determined
possible join orders for queries with nested outer and inner joins.
This could lead to invalid execution plans for such queries.

        The Geometry::get_mbr() function can return an error on
        a bad data. We have to check for that and act respectively.