- 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.


mysql-test/r/func_group.result:
  Backport bug #37348 fix 5.1 --> 5.0.
mysql-test/t/func_group.test:
  Backport bug #37348 fix 5.1 --> 5.0.
sql/item.cc:
  Backport bug #37348 fix 5.1 --> 5.0.
sql/item.h:
  Backport bug #37348 fix 5.1 --> 5.0.
sql/sql_select.cc:
  Backport bug #37348 fix 5.1 --> 5.0.

The problem is that XML functions(items) do not reset null_value
before their execution and further item excution may use
null_value value of the previous result.
The fix is to reset null_value.


mysql-test/r/xml.result:
  test result
mysql-test/t/xml.test:
  test case
sql/item_xmlfunc.cc:
  The problem is that XML functions(items) do not reset null_value
  before their execution and further item excution may use
  null_value value of the previous result.
  The fix is to reset null_value.

Problem: we don't prune a LESS THAN partition if MAXVALUE is given and
given value is equal to a LESS THAN value.

Fix: prune partitions in such cases.


mysql-test/r/partition.result:
  Fix for bug#42944: partition not pruned correctly
    - test result.
mysql-test/t/partition.test:
  Fix for bug#42944: partition not pruned correctly
    - test case.
sql/sql_partition.cc:
  Fix for bug#42944: partition not pruned correctly
    - prune partition if given value is equal to a LESS THAN value
      and it's not a "PARTITION ... LESS THAN MAXVALUE" one.

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

mysql_setpermission is modified to honor the $db 
variable as suggested when doing a REVOKE ALL for 
menu option 7.

+ disable the funcs_1.charset_collation_* tests which are broken because
  of bug 38346, 40209, 40545, 40618

          on 5.0            
The server crashes on an assert in net_end_statement indicating that the
Diagnostics area wasn't set properly during execution.
This happened on a multi table DELETE operation using the IGNORE keyword.
The keyword is suppose to allow for execution to continue on a best effort
despite some non-fatal errors. Instead execution stopped and no client
response was sent which would have led to a protocol error if it hadn't been
for the assert.
This patch corrects this issue by checking for the existence of an IGNORE
option before setting an error state during row-by-row delete iteration.


mysql-test/r/innodb_mysql.result:
  * Added test case for bug40127
mysql-test/t/innodb_mysql.test:
  * Added test case for bug40127
sql/sql_delete.cc:
  * IGNORE option wasn't implemented in multi_delete::send_data
    and multi_delete::do_deletes

Test was flakey on some machines and showed spurious
reds for races.

New-and-improved test makes do with fewer statements,
no mysqltest-variables, and no backticks. Should hope-
fully be more robust. Heck, it's debatable whether we
should have a test for this, anyway.

mysql-test/suite/rpl/r/rpl_temporary.result:
  streamlined
mysql-test/suite/rpl/t/rpl_temporary.test:
  streamlined

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.


mysql-test/r/trigger.result:
  Results for the added test case is added.
mysql-test/t/trigger.test:
  A new test case is added, verifying correct table multi-update
  conflict resolution, both read-only and write.
sql/sql_base.cc:
  The check for conflicting use of tables in SP/triggers is moved
  to lock_tables(), to be performed after the exact lock types
  have been determined. Also, an assert is added to open_ltable()
  to ensure this func is not used in a prelocked context.