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

- Call tmp_having->update_used_tables() *before* we have call JOIN::cleanup().
  Making the call after join::cleanup() is not allowed, because subquery 
  predicate items walk parent join's JOIN_TAB structures. Which can be 
  invalidated by JOIN::cleanup().

- Added testcase

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.

- Added testcase

- When restore_prev_nj_state() is called for the table that is 
  the last remaining child of a nested join, do not leave that
  nested join's bit in join->cur_embedding_map.

- make multi_delete::initialize_tables() take into account that the JOIN structure may have
  semi-join nests (which are not fully initialized when this function is called, they have 
  tab->table=NULL which caused the crash)
- Also checked multi_update::initialize_tables(): it has a different logic and needed no fixing.

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.

MDEV-4458 - Windows installer does not launch upgrade wizard anymore, even if there are upgradable instances (i.e windows service of lower MariaDB/MySQL version)

The main  reason for he error is misplaced ADD_DIRECTORY in top-level CMakeLists.txt.
ADD_DIRECTORY(win/packaging) was places before win/upgrade_wizard, and MSI was not able to detect that  upgrade wizard was built, and thus excluded upgrade wizard entirely.

The function make_join_statistics checks whether eq_ref access uses only
constant expressions, and, if this is the case the function performs
constant row substitution. The code of this check must take into account
hidden components of extended secondary keys. 

Since event types can be >=128 and are read from a (possibly signed) char
pointer, we need to cast to unsigned char before extending to int, or we will
get an incorrect negative number. This was done in the main code path already,
but there is a rare case where we check for new events first without a lock
and then again with the lock. If the second check succeeds because a new event
turns up at just the right time, then we took a code path that was missing the
correct unsigned char cast, leading to incorrect handling of events for old
slave servers and possibly other grief.

(This was found from a sporadic failure in Buildbot of test case
rpl_mariadb_slave_capability).

The problem was that xtradb has innodb_purge_threads default 1 (plain
innodb defaults to 0).

The test sets a special debug variable and relies on it to force
purge to happen. But when using background purge threads, this does
not work, the debug code is not made to handle this, so occasionally
the test times out waiting for the purge to occur.

Fix by explicitly setting innodb_purgee_threads=0 for this test.

Change default for innodb_use_fallocate to FALSE, due to bugs in older Linux kernels (posix_fallocate() does not always guarantee that file size is like one specified)

with a bit of lame protection against abuse.

The official Debian Wheezy MySQL packages have versions like 5.5.30+dfsg-xxx.
Such version is larger than 5.5.30-yyy, so apt prefers it.
So use instead 5.5.30+maria-yyy, which is larger and can be pulled in
automatically by apt.

Also included are a couple of fixes for test failures in buildbot.

This fixes that by default LOAD DATA INFILE will not generate the error:
"Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage..."


mysql-test/suite/sys_vars/r/max_binlog_cache_size_basic.result:
  Updated test case
mysql-test/suite/sys_vars/r/max_binlog_stmt_cache_size_basic.result:
  Updated test case
sql/sys_vars.cc:
  Increase default value of max_binlog_cache_size and max_binlog_stmt_cache_size to ulonglong_max.

(because only there it  makes any sense)

  
MySQL bug http://bugs.mysql.com/bug.php?id=61713 was fixed in 5.5
  
Fix is to remove check for multiple entries returned by getaddrinfo(), and use the first entry that works  - i.e socket can be created.  

Unlike Oracle/MySQL's fix ,this one  is kept minimal : 
-  we do not prioritize IPv4 over IPv6,  orr other way around,  and just rely on operating system to sort getaddrinfo() entries in sensible order. There is RFC that defines  what is sensible order for getaddrinfo entries ( RFC 3484), and OS specific tweaks are also possible , like /etc/gai.conf o Linux.
-  also,  we do not force "0.0.0.0" address if bind-address is not given -  this would be a change in behavior of 5.5 at least on Windows, where passing NULL as  to getaddrinfo()  gives back IPv6-wildcard.

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.