The feature was backported from MySQL 5.6.
Some code was added to make commands as
        SELECT * FROM ignored_db.t1;
        CALL ignored_db.proc();
        USE ignored_db;
to take that option into account.

per-file comments:
  mysql-test/r/ignore_db_dirs_basic.result
        test result added.
  mysql-test/t/ignore_db_dirs_basic-master.opt
        options for the test,
        actually the set of --ignore-db-dir lines.
  mysql-test/t/ignore_db_dirs_basic.test
        test for the feature.
        Same test from 5.6 was taken as a basis,
        then tests for SELECT, CALL etc were added.

per-file comments:
  sql/mysql_priv.h
MDEV-495 backport --ignore-db-dir.
        interface for db_name_is_in_ignore_list() added.
  sql/mysqld.cc
MDEV-495 backport --ignore-db-dir.
        --ignore-db-dir handling.
  sql/set_var.cc
MDEV-495 backport --ignore-db-dir.
        the @@ignore_db_dirs variable added.
  sql/sql_show.cc
MDEV-495 backport --ignore-db-dir.
        check if the directory is ignored.
  sql/sql_show.h
MDEV-495 backport --ignore-db-dir.
        interface added for opt_ignored_db_dirs.
  sql/table.cc
MDEV-495 backport --ignore-db-dir.
        check if the directory is ignored.

After pullout item during single row subselect transformation it should be fixed properly.

- Performed some refactoring and simplification that was enabled and required by the merge.

Analysis:
The queries in question use the [unique | index]_subquery execution methods.
These methods reuse the ref keys constructed by create_ref_for_key(). The
way create_ref_for_key() works is that it doesn't store in ref.key_copy[]
store_key elements that represent constants. In particular it doesn't store
the store_key for NULL constants.

The execution of [unique | index]_subquery calls
subselect_uniquesubquery_engine::copy_ref_key, which in addition to copy
the left IN argument into a index lookup key, is supposed to detect if
the left IN argument contains NULLs. Since the store_key for the NULL
constant is not copied into the key array, the null is not detected, and
execution erroneously proceeds as if it should look for a complete match.

Solution:
The solution (unlike MySQL) is to reuse already computed information about
NULL presence. Item_in_optimizer::val_int already finds out if the left IN
operand contains NULLs. The fix propagates this to the execution methods
subselect_[unique | index]subquery_engine::exec so it knows if there were
NULL values independent of the presence of keys.

In addition the patch siplifies copy_ref_key() and the logic that hanldes
the case of NULLs in the left IN operand.

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

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.

        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.

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)

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

force -fno-strict-aliasing for oqgraph

The problem was that was_null and null_value variables was reset in each reexecution of IN subquery, but engine rerun only for non-constant subqueries.

Fixed checking constant in Item_equal sort.
Fix constant reporting in Item_subselect.

Various places in the server replication code was incorrectly quoting
strings, which could lead to incorrect SQL on the slave/mysqlbinlog.

Item::get_date() should return 1 unless the value is a valid date.

two tests still fail:
  main.innodb_icp and main.range_vs_index_merge_innodb
  call records_in_range() with both range ends being open
  (which triggers an assert)

increase xtradb verson from 13.0 to 13.01