RBR should be turned off when statistical tables are modified 
in the result of the execution of a DDL statement.
Revised the fix for bug mdev-463. Ensured suppression of RBR
for the modifications of the statistical tables triggered
by the execution of any analyze operation.

Any Field object should use current_thd instead of table->in_use 
when THD is needed if table == NULL.
This patch fixes the crash of test case from mdev-504.test.

Opening system statistical tables and reading statistical data from 
them for a regular table should be done after opening and locking 
this regular table.
No test case is provided with this patch.

As far as we reopen tables so TABLE become invalid we should remove the pointer on cleanup().

The DELETE for emplicitly emptied MEMORY tables should be written directly to binlog.

Link view/derived table fields to a real table to check turning the table record to null row.

Item_direct_view_ref wrapper now checks if table is turned to null row.

MDEV-481 Assertion `pins->pin[i] == 0' failed in _lf_pinbox_put_pins on concurrent OPTIMIZE TABLE and DML with Aria tables

A bug in the lock-free hash implementation!
when lsearch() has not found the key, the caller needs to unpin all the three pins,
because lsearch() was using all the three.

   not every time.
2. Increase purgatory size.

include/lf.h:
  allocate larger purgatory
mysys/lf_alloc-pin.c:
  typo.

If a table is already in the table cache but without data from persistent
statistical tables then the function open_and_process_table should not
only allocate memory for this statistical data in the corresponding
TABLE_SHARE object, but also should copy the references to the data into
certain fields of the TABLE data structure: for each key of the table 
KEY::read_stats should be copied, and for each column of the table
Field::read_stats should be copied. 

        Autointersections of an object were treated as nodes, so the wrong result.

per-file comments:
  mysql-test/r/gis.result
Bug #1043845 st_distance() results are incorrect depending on variable order.
        test result updated.
  mysql-test/t/gis.test
Bug #1043845 st_distance() results are incorrect depending on variable order.
        test case added.
  sql/item.cc
        small fix to make compilers happy.
  sql/item_geofunc.cc
Bug #1043845 st_distance() results are incorrect depending on variable order.
        Skip intersection points when calculate distance.

MDEV-414 Depending on indexes or execution plans, a warning on incorrect or out of range values in WHERE condition is sometimes produced and sometimes not

use the same method that disables warnings in all relevant places, remove redundant function

When we append data to the binlog file, we use fdatasync() to ensure
the data gets to disk so that crash recovery can work.

Unfortunately there seems to be a bug in ext3/ext4 on linux, so that
fdatasync() does not correctly sync all data when the size of a file
is increased. This causes crash recovery to not work correctly (it
loses transactions from the binlog).

As a work-around, use fsync() for the binlog, not fdatasync(). Since
we are increasing the file size, (correct) fdatasync() will most
likely not be faster than fsync() on any file system, and fsync()
does work correctly on ext3/ext4. This avoids the need to try to
detect if we are running on buggy ext3/ext4.

store the precision in uint, not uint8

MDEV-438 Microseconds: Precision is ignored in CURRENT_TIMESTAMP(N) when it is given as a default column value

The syntax for specifying precision in the DEFAULT clause is unintentional and unsupported.
Don't allow it anymore.

1. Field_newdate::get_date should refuse to return a date with zeros when
   TIME_NO_ZERO_IN_DATE is set, not when TIME_FUZZY_DATE is unset
2. Item_func_to_days and Item_date_add_interval can only work with valid dates,
   no zeros allowed.

fix Item_func_add_time::get_date() to generate valid dates.
Move the validity check inside get_date_from_daynr()
instead of relying on callers
(5 that had it, and 2 that did not, but should've)

Split ER_NO_SUCH_TABLE into ER_NO_SUCH_TABLE and ER_NO_SUCH_TABLE_IN_ENGINE to be able to distingus if a .frm file is missing or if the table is missing in the engine.


sql/handler.cc:
  Added ER_NO_SUCH_TABLE_IN_ENGINE
sql/rpl_record.cc:
  Fixed wrong printf
sql/share/errmsg-utf8.txt:
  Added ER_NO_SUCH_TABLE_IN_ENGINE
sql/sp.cc:
  Added ER_NO_SUCH_TABLE_IN_ENGINE
sql/sp_head.cc:
  Added ER_NO_SUCH_TABLE_IN_ENGINE
sql/sql_admin.cc:
  Added ER_NO_SUCH_TABLE_IN_ENGINE
sql/sql_base.cc:
  Added ER_NO_SUCH_TABLE_IN_ENGINE
sql/sql_show.cc:
  Added ER_NO_SUCH_TABLE_IN_ENGINE
sql/table.cc:
  Fixed typo

MDEV-405: Server crashes in test_if_skip_sort_order on EXPLAIN with GROUP BY and HAVING in EXISTS subquery
- Testcase

- Don't do early cleanup of uncorrelated subqueries if we're running an EXPLAIN.

        the fill_help_table-5.5.sql file was copied into mariadb.

per-file comments:
  scripts/fill_help_tables.sql
        MDEV-471 update help tables.

storage engine in HA_MRR_NO_ASSOCIATION mode.
(there is no testcase because we don't ship any such engines currently)

The function collect_statistics_for_table() when scanning a table
did not take into account that the handler function ha_rnd_next
could return the code HA_ERR_RECORD_DELETE that should not be
considered as an indication of an error.
Also fixed a potential memory leak in this function.