for indexes of InnoDB table

Fixes by replacing the PRNG that is used to pick random pages with a 
better one. 

Also adds a configuration option "innodb_use_legacy_cardinality_algorithm"
to enable the fix only when the option is set.

This patch is from http://bugs.mysql.com/file.php?id=11789

QUERY statement
      
Commit 55629 applied to 5.0-bugteam and 5.1-bugteam: 
Check for thd->killed in CHECKSUM loop.

mysqldump.test is designed to run with concurrent inserts
disabled. It is disabling concurrent inserts at the very
beginning of the test case, and re-enables them at the
bottom of the test. But for some reason (likely incorrect
merge) we enable concurrent inserts in the middle of the test.

The problem is fixed by enabling concurrent inserts only
at the bottom of the test case.

  to wrong results
      
3 problems found with DES_ENCRYPT/DES_DECRYPT :

1. The max length was not calculated properly. Fixed in fix_length_and_dec()
2. DES_ENCRYPT had a side effect of sometimes reallocating and changing 
the value of its argument. Fixed by explicitly pre-allocating the necessary
space to pad the argument with trailing '*' (stars) when calculating the 
DES digest.
3. in DES_ENCRYPT the string buffer for the result value was not 
reallocated to the correct size and only string length was assigned to it. 
Fixed by making sure there's enough space to hold the result.

information schema tables are based on internal tmp tables which are removed
after each statement execution. So HANDLER comands can not be used with
information schema.

Streamlined how we increase the size of our test table.
The new method shows run time decreased by ~60%.
This is not a guarantee that we will not see test timeouts (the random failures noted in the bug),
but it should significantly reduce the chances of this occurring.

fixed message for 'help' command

routine does not exist 
      
There is an inconsistency with DROP DATABASE IF EXISTS, DROP TABLE IF
EXISTS and DROP VIEW IF EXISTS: those are binlogged even if the DB or
TABLE does not exist, whereas DROP PROCEDURE IF EXISTS does not. It
would be nice or at least consistent if DROP PROCEDURE/STATEMENT
worked the same too.
      
Fixed DROP PROCEDURE|FUNCTION IF EXISTS by adding a call to
mysql_bin_log.write in mysql_execute_command. Checked also if all 
documented "DROP (...) IF EXISTS" get binlogged.
      
NOTE: This is a 5.0 backport patch as requested by support.

The crash happens due to wrong 'digits' variable value(0),
'digits' can not be 0, so the fix is use 1 as min allowed value.

While printing the Max keyfile length 'llstr' call was used which 
was treating the max_key_file_length as negative.

Changing this to ullstr fixes the problem. 
myisamchk output will differ in 32 bit and 64 bit Operating systems 
so its not possible to have test case for this bug.

      
The test started failing following the push for BUG#41541.
Some of the algorithms access bytes beyond the input data
and this can affect up to one byte less than "word size"
which is BITS_SAVED / 8. 
      
Fixed by adding (BITS_SAVED / 8) -1 bytes to buffer size
(i.e. Memory Segment #2) to avoid accessing un-allocated data.

The problem is that a SELECT .. FOR UPDATE statement might open
a table and later wait for a impeding global read lock without
noticing whether it is holding a table that is being waited upon
the the flush phase of the process that took the global read
lock.

The same problem also affected the following statements:

LOCK TABLES .. WRITE
UPDATE .. SET (update and multi-table update)
TRUNCATE TABLE ..
LOAD DATA ..

The solution is to make the above statements wait for a impending
global read lock before opening the tables. If there is no
impending global read lock, the statement raises a temporary
protection against global read locks and progresses smoothly
towards completion.

Important notice: the patch does not try to address all possible
cases, only those which are common and can be fixed unintrusively
enough for 5.0.

Bug#32136: mysqld_multi --defaults-file not respected while using \
	--mysqld=mysqld_safe

Revert change that adds "--no-defaults" to mysqld_multi.

This closes Bug#43508 and re-opens Bug#32136.

- Link against setargv.obj for wild-card expansion.

Original commentary:

Bug #37348: Crash in or immediately after JOIN::make_sum_func_list
            
The optimizer pulls up aggregate functions which should be aggregated in
an outer select. At some point it may substitute such a function for a field
in the temporary table. The setup_copy_fields function doesn't take this
into account and may overrun the copy_field buffer.
            
Fixed by filtering out the fields referenced through the specialized
reference for aggregates (Item_aggregate_ref).
Added an assertion to make sure bugs that cause similar discrepancy 
don't go undetected.

- Link against setargv.obj for wild-card expansion.

more for completeness than for relevance.

Also, update copyright notices.

updates

Attempt to execute trigger or stored function with multi-UPDATE
which used - but didn't update - a table that was also used by
the calling statement led to an error. Read-only reference to
tables used in the calling statement should be allowed.
 
This problem was caused by the fact that check for conflicting
use of tables in SP/triggers was performed in open_tables(),
and in case of multi-UPDATE we didn't know exact lock type at
this stage.

We solve the problem by moving this check to lock_tables(), so
it can be performed after exact lock types for tables used by
multi-UPDATE are determined.

  
UNION could convert fixed-point FLOAT(M,D)/DOUBLE(M,D) columns  
to FLOAT/DOUBLE when aggregating data types from the SELECT  
substatements. While there is nothing particularly wrong with  
this behavior, especially when M is greater than the hardware  
precision limits, it could be confusing in cases when all  
SELECT statements in a union have the same  
FLOAT(M,D)/DOUBLE(M,D) columns with equal precision  
specifications listed in the same position.  
  
Since the manual is quite vague on what data type should be  
returned in such cases, the bug was fixed by implementing the  
most 'expected' behavior: do not convert FLOAT(M,D)/DOUBLE(M,D)  
to anything else if all SELECT statements in a UNION have the  
same precision for that column.  

Problem: commit doesn't delete savepoints if there are no changes 
in the transaction.

Fix: delete them in such cases.