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)