Problem was in caching 'eq_ref' dependency between calls of remove_const() for ORDER BY and GROUP BY lists.

Fix embedded/windows tests- move COND_manager and LOCK_manager to sql_manager.cc, to prevent race condition  that results into accessing already destroyed critical section

The cause of this bug was the same as for bug 902356 fixed for 5.3.

A table expression with a natural join or a USING clause is transformed
into an equivalent expression with equi-join ON conditions. If a reference
to a virtual column happened to occur only in these generated equi-join
conditions then it was not erroneously marked in the TABLE::vcol_set bitmap.
This could lead to wrong results for queries containing natural join
expressions or USING clauses. 

The method Item_sum_num::fix_fields() calculated the value of
the flag Item_sum_num::maybe_null in some cases incorrectly.

The MIN/MAX optimization cannot be applied to a subquery if its WHERE clause
contains a conjunctive condition depending on an outer reference.

The MIN/MAX optimizer code from the function opt_sum_query erroneously
did not take into account conjunctive conditions that did not depend on
any table, yet were not identified as constant items. These could be
items containing rand() or PS/SP parameters. These items are supposed
to be evaluated at the execution phase. That's why if such conditions
can be extracted from the WHERE condition the MIN/MAX optimization is
not applied as currently it is always done at the optimization phase.

(In 5.3 expensive subqueries are also evaluated only at the execution
phase. So, if a constant condition with such subquery can be extracted
from the WHERE clause the MIN/MAX optimization should not be applied 
in 5.3.)

IF an IN/ALL/SOME predicate with a constant left part is transformed
into an EXISTS subquery the resulting subquery should not be considered
uncacheable if the right part of the predicate is not uncacheable.

Backported the function dbug_print_item() from 5.3. The function is used
only for debugging.  
 

- dijkstra_shortest_paths() needs a Graph as first parameter, in case of reverse_graph we now need to use
  its m_g member
- use boost::tuples::tie() on all places where tie() was used . Reason -
  fix the build with Visual Studio 10 SP1 (which includes std:tr1:tie, thus creating  ambiguity)

sql/sql_parse.cc:
  Only call ha_maria::implicit_commit if aria is enabled

The function st_table::mark_virtual_columns_for_write() did not take into
account the fact that for any table the value of st_table::vfield is 0
when there are no virtual columns in the table definition.

If the sorted table belongs to a dependent subquery then the function
create_sort_index() should not clear TABLE:: select and TABLE::select
for this table after the sort of the table has been performed, because
these members are needed for the second execution of the subquery.

 

Updated version number in configure

mysql-test/suite/maria/r/maria-recovery3.result:
  Added test case for recovery bug
mysql-test/suite/maria/t/maria-recovery3.test:
  Added test case for recovery bug
storage/maria/ha_maria.cc:
  Don't print query twice to log
storage/maria/ma_delete.c:
  More DBUG_PRINT
storage/maria/ma_key_recover.c:
  Added new asserts to detect errors earlier
storage/maria/ma_recovery.c:
  Update all states when moving a non-transactional file to transactional. This fixes lp:887051

The range optimizer incorrectly chose a loose scan for group by
when there is a correlated WHERE condition. This range access
method cannot be executed for correlated conditions also with the
"range checked for each record" because generally the range access
method can change for each outer record. Loose scan destructively
changes the query plan and removes the GROUP operation, which will
result in wrong query plans if another range access is chosen
dynamically.

Removed previous patch of this problem.

Analysis:
The class member QUICK_GROUP_MIN_MAX_SELECT::seen_first_key
was not reset between subquery re-executions. Thus each
subsequent execution continued from the group that was
reached by the previous subquery execution. As a result
loose scan reached end of file much earlier, and returned
empty result where it shouldn't.

Solution:
Reset seen_first_key before each re-execution of the
loose scan.

Fixed feedback_plugin_send to not generate a random number of lines.


mysql-test/t/feedback_plugin_send.test:
  Don't print more than 4 lines (sometimes there are 6 feedback lines in the log...)
mysql-test/valgrind.supp:
  Added suppression for failure on work
support-files/compiler_warnings.supp:
  Suppress warning from xtradb

2. dialog plugin now always returns mysql->password if non-empty and the first question is of password type
3. split get_tty_password into get_tty_password_buff and strdup.
4. dialog plugin now uses get_tty_password by default
5. dialog.test
6. moved small tests of individual plugins into a dedicated suite

mysql-test/suite/maria/t/compat_aliases-master.opt:
  Fixed wrong limit
storage/example/ha_example.cc:
  Fixed compiler warning

Fixed bug where automaticly zerofilled table was not part of recovery if crash happended before next checkpoint.


mysql-test/suite/maria/r/maria-autozerofill.result:
  Updated test case
storage/maria/ha_maria.cc:
  Write create_rename_lsn for auto_zerofilled tables.
storage/maria/ma_delete.c:
  Added DBUG_ASSERT() to find errors when deleting pages.
storage/maria/ma_locking.c:
  Fixed typo
storage/maria/ma_open.c:
  Don't regard file as movable if create_rename_lsn is not LSN_NEEDS_NEW_STATE_LSNS

After sending packet that is too large, clienrt can get either an error packet with 
ER_NET_PACKET_TOO_LARGE, or a socket error. Both cases are valid, since the
server does not ensure reply was fully read by client, before shutting down  and closing 
the socket.