Handle commit of zero operations

into mysql.com:/home/jonas/src/mysql-4.1-ndb

(bad merge from 4.0)

  Added catch for (example) WL#1234 into bk commit subjects

propogation works only once (prepared statements)".

- 'ps_10nestset' uses a "nested set" approach for an employee 
  hierarchy, then does arithmetic on the "salary" field;
  (soon) to be extended by inserts / deletes which imply
  mass updates on the "l"/"r" fields showing the set inclusion,
- 'ps_11bugs' will get (some of ?) those bug DB entries which
  refer to prepared statements, but whose number does not appear
  in a test file comment - so it will also be extended.

  A fix for Bug#6042 "constants propogation works olny once (prepared
  statements)": reset item->marker in Item::cleanup, as it's used
  in propogate_cond_constants. No test case as the only way I could
  come up with to show the problem is EXPLAIN, and EXPLAIN is painful
  to use in the test suite.

into poseidon.ndb.mysql.com:/home/tomas/mysql-4.1-ndb

into poseidon.ndb.mysql.com:/home/tomas/mysql-4.1

into a193-229-222-105.elisa-laajakaista.fi:/home/my/bk/mysql-4.1

section, which had gotten somewhat out-dated.

into mysql.com:/home/jonas/src/mysql-4.1-ndb

into poseidon.ndb.mysql.com:/home/tomas/mysql-4.1-ndb-merge

into gw.mysql.r18.ru:/usr/home/ram/work/4.1.b5382

into poseidon.ndb.mysql.com:/home/tomas/mysql-4.1

into mysql.com:/home/jonas/src/mysql-4.1-ndb

into poseidon.ndb.mysql.com:/home/tomas/mysql-4.1-ndb-merge

into poseidon.ndb.mysql.com:/home/tomas/mysql-4.1

Fixes bug with tableImpl with blobs not being initialized properly w.r.t pointer to blob tableImpl in column
    added blob to test to see that blob tables don't show up in show tables
    auto increment setting need not fetch blob tables (will otherwise generate error during table creation)
    moved addBlobTables out of fetchGlobalTableImpl to get_local_table_info
    changed addBlobTables to start from last column and break if all blobs added
    also addBlobTables will return -1 if failed (typically getTable)
    changed to using get_local_table_info with internal table name where applicable for efficiency
    added option to get_local_table_info wether to fetch blob tables or not
    getTable always fetches the blobtables
    moved addBlobTables to get_local_table_info to always be called, even if main table goes to cache only

into gw.mysql.r18.ru:/usr/home/ram/work/4.1.gconcat

(Bug #4315: GROUP_CONCAT with ORDER BY returns strange results for TEXT fields
 Bug #5564: Strange behaviour with group_concat and distinct
 Bug #5970: group_concat doesn't print warnings)

change, and perform it (the new Item changes registry).

into mysql.com:/media/sda1/mysql/mysql-4.1-hook

crashes server (prepared statements)": the bug was that all boolean
items always recovered its original arguments at statement cleanup 
stage.
This collided with Item_subselect::select_transformer, which tries to 
permanently change the item tree to use a transformed subselect instead of
original one.
So we had this call sequence for prepare:
mysql_stmt_prepare -> JOIN::prepare -> 
Item_subselect::fix_fields -> the item tree gets transformed ->
Item_bool_rowready_func2::cleanup, item tree is recovered to original
state, while it shouldn't have been;
mysql_stmt_execute -> attempts to execute a broken tree -> crash.
Now instead of bluntly recovering all arguments of bool functions in 
Item_bool_rowready_func2::cleanup, we recover only those
which were changed, and do it in one place.
There still would exist a possibility for a collision with subselect
tranformation, if permanent and temporary changes were performed at the 
same stage.
But fortunately subselect transformation is always done first, so it 
doesn't conflict with the optimization done by propogate_cond_constants.
Now we have: 
mysql_stmt_prepare -> JOIN::prepare -> subselect transformation 
permanently changes the tree -> cleanup doesn't recover anything, 
because nothing was registered for recovery.
mysql_stmt_execute -> JOIN::prepare (the tree is already transformed, 
so it doesn't change), JOIN::optimize -> 
propogate_cond_constants -> temporary changes the item tree 
with constants -> JOIN::execute -> cleanup -> 
the changes done by propogate_cond_constants are recovered, as
they were registered for recovery.