batch_readline_init() was modified - return an error
if the input source is a directory or a block device.

This follow-up is necessary because on some platforms,
such as Solaris, call to read() from directory may be
successful.

Resolved an innodb conflict thanks to vasil.

Test failed on a certain Linux platform in automated environment. It turns out that this platform has an old version of Perl modules DBI and DBD::mysql installed, as well as the OS itself being relatively old.
Allowing error code 11 to be returned from mysqlhotcopy on expected error seems harmless and will make the test pass also with older libraries.

Removed the collections for mysql-5.1-bugteam. Removed 1st from weekly. This is part of default suites

Removed the collections for mysql-5.1-bugteam. Removed 1st from weekly. This is part of default suites

rb://566
approved by: Sunny

When using native aio on linux each IO helper thread should be able to
handle upto 256 IO requests. The number 256 is the same which is used
for simulated aio as well. In case of windows where we also use native
aio this limit is 32 because of OS constraints. It seems that we are
using the limit of 32 for all the platforms where we are using native
aio. The fix is to use 256 on all platforms except windows (when native
aio is enabled on windows)

This change was backported from 5.5.

This warning also happens in 5.1 with a slightly different codepath.

function privileges" into 5.5 tree. Did after-merge fixes.

function privileges" into 5.5 tree. Did after-merge fixes.

Added --debug-server and use $opt_debug_server where appropriate
Let --debug imply --debug-server
When merging to 5.5, must adapt fix for 59148
Oops, set debug => debug-server too late, fixed

privileges".

The first problem was that DROP USER didn't properly remove privileges 
on stored functions from in-memory structures. So the dropped user
could have called stored functions on which he had privileges before
being dropped while his connection was still around.
Even worse if a new user with the same name was created he would
inherit privileges on stored functions from the dropped user.
Similar thing happened with old user name and function privileges
during RENAME USER.

This problem stemmed from the fact that the handle_grant_data() function
which handled DROP/RENAME USER didn't take any measures to update
in-memory hash with information about function privileges after
updating them on disk.

This patch solves this problem by adding code doing just that.

The second problem was that RENAME USER didn't properly update in-memory
structures describing table-level privileges and privileges on stored 
procedures. As result such privileges could have been lost after a rename
(i.e. not associated with the new name of user) and inherited by a new
user with the same name as the old name of the original user.

This problem was caused by code handling RENAME USER in
handle_grant_struct() which [sic!]:
a) tried to update wrong (tables) hash when updating stored procedure
   privileges for new user name.
b) passed wrong arguments to function performing the hash update and
   didn't take into account the way in which such update could have
   changed the order of the hash elements.

This patch solves this problem by ensuring that a) the correct hash
is updated, b) correct arguments are used for the hash_update()
function and c) we take into account possible changes in the order
of hash elements.

mysql-test/r/grant.result:
  Added test coverage for bug#36544 "DROP USER does not remove stored
  function privileges".
mysql-test/suite/funcs_1/r/innodb_storedproc_06.result:
  Since after fixing bug#36544 "DROP USER does not remove stored function
  privileges" in-memory structures are correctly updated by DROP USER,
  DROP FUNCTION performed after DROP USER for its definer no longer
  produces unwarranted warning/error messages.
mysql-test/suite/funcs_1/r/memory_storedproc_06.result:
  Since after fixing bug#36544 "DROP USER does not remove stored function
  privileges" in-memory structures are correctly updated by DROP USER,
  DROP FUNCTION performed after DROP USER for its definer no longer
  produces unwarranted warning/error messages.
mysql-test/suite/funcs_1/r/myisam_storedproc_06.result:
  Since after fixing bug#36544 "DROP USER does not remove stored function
  privileges" in-memory structures are correctly updated by DROP USER,
  DROP FUNCTION performed after DROP USER for its definer no longer
  produces unwarranted warning/error messages.
mysql-test/t/grant.test:
  Added test coverage for bug#36544 "DROP USER does not remove stored
  function privileges".
sql/sql_acl.cc:
  Changed handle_grant_data() to also update hash with function 
  privileges. This allows DROP/RENAME USER correctly keep this 
  in-memory structure up-to-date.
  
  To do this extended handle_grant_struct() to support updating of this
  hash. In addition fixed code in this function which is responsible for 
  handling of column and routine hashes during RENAME USER, ensured that
  we correctly update these hashes after changing user name and that we
  don't skip elements while iterating through the hash and doing updates.

The problem was overflow in max_length when we tried to des_decrypt()
something which is not the output of des_encrypt()


mysql-test/r/ssl_and_innodb.result:
  New test case.
mysql-test/t/ssl_and_innodb.test:
  New test case.
sql/item_strfunc.h:
  Do not subtract the encrypt overhead (9U) if args[0] has length < 9
  (In unsigned arithmetic, (1-9) becomes a very large number)

      
Also fix bug#59110: Memory leak of QUICK_SELECT_I allocated memory.
Includes Jørgen Lølands review comments.
      
Root cause of these bugs are that test_if_skip_sort_order() decided to
revert the 'skip_sort_order' descision (and use filesort) after the
query plan has been updated to reflect a 'skip' of the sort order.
      
This might happen in 'check_reverse_order:' if we have a 
select->quick which could not be made descending by appending 
a QUICK_SELECT_DESC. ().
      
The original 'save_quick' was then restored after the QEP has been modified,
which caused:
      
  - An incorrect 'precomputed_group_by= TRUE' may have been set, 
    and not reverted, as part of the already modifified QEP (Bug#59308)
  - A 'select->quick' might have been created which we fail to delete (bug#59110).
      
This fix is a refactorication of test_if_skip_sort_order() where all logic
related to modification of QEP (controlled by argument 'bool no_changes'), is
moved to the end of test_if_skip_sort_order(), and done after *all* 'test_if_skip'
checks has been performed - including the 'check_reverse_order:' checks.
      
The refactorication above contains now intentional changes to the logic which 
has been moved to the end of the function.
      
Furthermore, a smaller part of the fix address the handling of the 
select->quick objects which may already exists when we call 
'test_if_skip_sort_order()' (save_quick) -and
new select->quick's created during test_if_skip_sort_order():
      
  - Before new select->quick may be created by calling ::test_quick_select(), we
    set 'select->quick= 0' to avoid that ::test_quick_select() prematurely
    delete the save_quick's. (After this call we may have both a 'save_quick' 
    and 'select->quick')
      
  - All returns from ::test_if_skip_sort_order() where we may have both a
    'save_quick' and a 'select->quick' has been changed to goto's to the
    exit points 'skiped_sort_order:' or 'need_filesort:' where we
    decide which of the QUICK_SELECT's to keep, and delete the other.

used (--with-zlib-dir=bundled) then there is no libz.so involved.