- MySQL 5.5 introduced caching of constant items by means of 
  wrapping them in Item_cache_XXX objects. If a subquery was wrapped
  in this cache, it could end up being pushed down by ICP.
- The fix is to add Item_cache::walk() which lets ICP to see that 
  the cache item has a subquery inside it, and disable pushdown for this case.

- In MySQL 5.5, print_join() was re-worked to print "FROM dual" when all
  tables are constant. This change didn't work together with table 
  elimination.

Files copied from Percona-Server-5.5.20-rel24.1.tar.gz source tarball.

Problem was that now we can merge derived table (subquery in the FROM clause).
Fix: in case of detected conflict and presence of derived table "over" the table which cased the conflict - try materialization strategy.

The replication slave sets first error 1913 and immediately after error
1595. Thus it is possible, but unlikely, to get 1913. The original test
seems to realise this, but uses an invalid error code - my guess is
that this was a temporary code used in a feature tree, which was then
forgotten to be fixed when merged to main. The removed "1923" is
something committed by mistake during tests.

tests for RTree keys recovery.

- Make equality propagation work correctly when done inside the OR branches 

If the flag 'optimize_join_buffer_size' is set to 'off' and the value
of the system variable 'join_buffer_size' is greater than the value of
the system variable 'join_buffer_space_limit' than no join cache can
be employed to join tables of the executed query.
A bug in the function JOIN_CACHE::alloc_buffer allowed to use join
buffer even in this case while another bug in the function 
revise_cache_usage could cause a crash of the server in this case if the
chosen execution plan for the query contained outer join or semi-join
operation.  

locked until we have finished clean up.

Previously, the code released the lock without marking that the thread
was running. This allowed a new slave thread to start while the old one
was still in the middle of cleaning up, causing assertions and probably
general mayhem.

Protocol documentation (http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol)
says that initial packet sent by client if client wants SSL, consists of client capability flags only
(4 bytes or 2 bytes edependent on protocol versionl). 
Some clients happen to send more in the initial SSL packet (C client, Python connector), while others (Java, .NET) follow the docs and send only client capability flags.

A change that broke Java client was a newly introduced check that frst client packet
has 32 or more bytes. This is generally wrong, if client capability flags contains CLIENT_SSL.

Also, fixed the code such that read max client packet size and charset in the first packet prior to SSL handshake.  With SSL, clients do not have to send this info, they can only send client flags.

This is now fixed such that max packet size and charset are not read prior to SSL handshake, in case of SSL they are read from the "complete" client authentication packet after SSL initialization.

The code was accessing a pointer in a mem_root that might be freed by
another concurrent thread. Fix by moving the access to be done while the
LOCK_thd_data is held, preventing the memory from being freed too early.

Fix of set_limit in case of an error (actually impossible case but better it will be right)

The bug itself is fixed by the patch for bug lp:908269.

 - mysql-test-run.pl --valgrind complains when all tests succeed.

 - perfschema.all_instances fail on non-linux, where ENABLE_TEMP_POOL
   is not set and therefore BITMAP mutex is not used.

 - MDEV-132: main.mysqldump fails because it depends on exact size of stdio
   buffers.

 - MDEV-99: rpl.rpl_cant_read_event_incident fails due to a race where the
   slave manages to connect while the test case is in the middle of setting up
   the master, causing the slave to replicate extra/wrong events.

 - MDEV-133: rpl.rpl_rotate_purge_deadlock fails because it issues a
   DEBUG_SYNC SIGNAL immediately followed by RESET; this means that sometimes
   the intended receipient has no time to see the signal before it is cleared
   by the RESET, causing wait to timeout.

test passes.