Changes in SQL parser:
 * Change default mode of SELECT from "lock in share mode"
   to "consistent read".
 * Remove support from SELECT for specifying "consistent read".
 * Add support in SELECT for specifying "lock in share mode".
 * Change all uses of SQL parser to specify "lock in share mode".
 * Modify syntax so that the only valid top-level statement is
   a procedure definition, since it's the only one that actually
   works.
 * Add support for lock waits.


sql/ha_innodb.cc:
  Applied innodb-5.1-ss660 snapshot.
   Document better the "bool table_id" flag.
storage/innobase/btr/btr0cur.c:
  Applied innodb-5.1-ss660 snapshot.
   btr_cur_search_to_nth_level(): Reacquire btr_search_latch after
   inserting to the insert buffer. This was noticed while analysing
   Bug#19801, but this should not fix this bug since, according to
   Heikki, btr_search_latch is not reserved during an insert.
storage/innobase/configure.in:
  Applied innodb-5.1-ss660 snapshot.
   Add -Wpointer-arith to CFLAGS when using GCC.
storage/innobase/data/data0type.c:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/dict/dict0crea.c:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/dict/dict0dict.c:
  Applied innodb-5.1-ss660 snapshot.
   Make dict_remove_db_name() non-static.
storage/innobase/ibuf/ibuf0ibuf.c:
  Applied innodb-5.1-ss660 snapshot.
   ibuf_fixed_addr_page(): Add parameter space. As the insert buffer
   B-tree is only located in the system tablespace (space 0),
   IBUF_TREE_ROOT_PAGE_NO is only special in space 0.
storage/innobase/include/data0type.h:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/include/dict0dict.h:
  Applied innodb-5.1-ss660 snapshot.
   Make dict_remove_db_name() non-static.
storage/innobase/include/pars0grm.h:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/include/pars0pars.h:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/include/que0que.h:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/include/sync0rw.ic:
  Applied innodb-5.1-ss660 snapshot.
   rw_lock_s_unlock_func(): Change a debug assertion to a
   production assertion in order to track down Bug#19081.
storage/innobase/include/trx0trx.h:
  Applied innodb-5.1-ss660 snapshot.
   trx_sig_send() always succeeds or asserts.
storage/innobase/include/ut0ut.h:
  Applied innodb-5.1-ss660 snapshot.
   Document better the "bool table_id" flags.
storage/innobase/mem/mem0mem.c:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/pars/lexyy.c:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/pars/pars0grm.c:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/pars/pars0grm.h:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/pars/pars0grm.y:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/pars/pars0lex.l:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/pars/pars0pars.c:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/que/que0que.c:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/row/row0mysql.c:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/row/row0sel.c:
  Applied innodb-5.1-ss660 snapshot.
   * Disable prefetch and adaptive hash index for tables
     with rows over 1024 bytes in InnoDB's SQL parser.
   * row_sel_try_search_shortcut(): Do not return SEL_FOUND
     when the record was not found. This bug was introduced
     in MySQL/InnoDB 5.0.3, but luckily it should never
     manifest itself, given that existing InnoDB SQL code
     never makes use of consistent reads.
   * Don't take unnecesary locks on supremum records when the
     srv_locks_unsafe_for_binlog option is enabled. Fixes an
     assertion failure in the innodb_unsafe_binlog testcase
     when compiled with UNIV_DEBUG.
storage/innobase/row/row0upd.c:
  Applied innodb-5.1-ss660 snapshot.
storage/innobase/trx/trx0roll.c:
  Applied innodb-5.1-ss660 snapshot.
   trx_sig_send() always succeeds or asserts.
storage/innobase/trx/trx0trx.c:
  Applied innodb-5.1-ss660 snapshot.
   trx_sig_send() always succeeds or asserts.
storage/innobase/ut/ut0ut.c:
  Applied innodb-5.1-ss660 snapshot.
   Document better the "bool table_id" flags.

into  mysql.com:/home/alexi/innodb/mysql-5.1-work
 Null merge.


storage/innobase/btr/btr0cur.c:
  Null merge.
storage/innobase/ibuf/ibuf0ibuf.c:
  Null merge.
storage/innobase/include/sync0rw.ic:
  Null merge.

innobase/btr/btr0cur.c:
  Applied innodb-5.0-ss660 snapshot.
   btr_cur_search_to_nth_level(): Reacquire btr_search_latch after
   inserting to the insert buffer. This was noticed while analyzing
   Bug#19081 but this shold not fix this bug since according to
   Heikki, btr_search_latch is not reserved during an insert.
innobase/ibuf/ibuf0ibuf.c:
  Applied innodb-5.0-ss660 snapshot.
   ibuf_fixed_addr_page(): Add parameter space. As the insert buffer
   B-tree is only located in the system tablespace (space 0),
   IBUF_TREE_ROOT_PAGE_NO is only special in space 0.
innobase/include/sync0rw.ic:
  Applied innodb-5.0-ss660 snapshot.
   rw_lock_s_unlock_func(): Change a debug assertion to a
   production assertion in order to track down Bug#19081.

into  mysql.com:/home/alexi/innodb/mysql-5.0-work
  Null merge.


innobase/ibuf/ibuf0ibuf.c:
  Null merge.

innobase/ibuf/ibuf0ibuf.c:
  Applied innodb-4.1-ss32 snapshot.
   ibuf_fixed_addr_page(): Add parameter space. As the insert
   buffer B-tree is only located in the system tablespace
   (space 0), IBUF_TREE_ROOT_PAGE_NO is only special in space 0.

into  dl145k.mysql.com:/data0/mkindahl/bk/mysql-5.1-new-rpl


sql/ha_federated.cc:
  Auto merged

into  dl145k.mysql.com:/data0/mkindahl/bk/mysql-5.1-new-rpl


storage/ndb/include/kernel/GlobalSignalNumbers.h:
  Auto merged
storage/ndb/src/kernel/blocks/dbdict/Dbdict.cpp:
  Auto merged
storage/ndb/src/kernel/blocks/dbdict/Dbdict.hpp:
  Auto merged
storage/ndb/src/kernel/blocks/dbdih/DbdihMain.cpp:
  Auto merged
storage/ndb/src/ndbapi/ndberror.c:
  Auto merged

mysql-test/r/rpl_switch_stm_row_mixed.result:
  Result change
sql/sql_class.h:
  Post-merge fixes.

into  trift2.:/M51/merge-5.1


mysql-test/r/federated.result:
  Auto merged
mysql-test/t/federated.test:
  Auto merged

into  trift2.:/M51/merge-5.1


configure.in:
  Auto merged
mysql-test/t/federated.test:
  Auto merged
sql/ha_federated.cc:
  Auto merged
sql/mysqld.cc:
  Auto merged
mysql-test/r/federated.result:
  SCCS merged
sql/ha_federated.h:
  ?
  ?
  Use local.

into  dl145k.mysql.com:/data0/mkindahl/bk/MERGE/mysql-5.1-merge


include/my_sys.h:
  Auto merged
mysql-test/mysql-test-run.pl:
  Auto merged
mysql-test/r/rpl_row_create_table.result:
  Auto merged
mysql-test/t/disabled.def:
  Auto merged
mysql-test/t/rpl_row_create_table.test:
  Auto merged
mysys/my_malloc.c:
  Auto merged
server-tools/instance-manager/parse.h:
  Auto merged
sql/ha_ndbcluster.cc:
  Auto merged
sql/handler.h:
  Auto merged
sql/log.cc:
  Auto merged
sql/log_event.cc:
  Auto merged
sql/mysql_priv.h:
  Auto merged
sql/set_var.h:
  Auto merged
sql/sp.cc:
  Auto merged
sql/sp_head.cc:
  Auto merged
sql/sp_head.h:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/sql_class.cc:
  Auto merged
sql/sql_insert.cc:
  Auto merged
sql/sql_lex.h:
  Auto merged
sql/sql_parse.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/sql_table.cc:
  Auto merged
sql/sql_update.cc:
  Auto merged
sql/sql_view.cc:
  Auto merged
sql/sql_yacc.yy:
  Auto merged
mysys/safemalloc.c:
  Merge of mysql-5.1-new-rpl into mysql-5.1
sql/ha_federated.cc:
  d
  Merge of mysql-5.1-new-rpl into mysql-5.1
sql/set_var.cc:
  Merge of mysql-5.1-new-rpl with mysql-5.1
sql/slave.cc:
  Merge of mysql-5.1-new-rpl into mysql-5.1
sql/sql_class.h:
  Merge of mysql-5.1-new-rpl into mysql-5.1

into  chilla.local:/home/mydev/mysql-5.1-amerge

into  dl145k.mysql.com:/data0/mkindahl/bk/MERGE/mysql-5.0-merge


ndb/include/kernel/GlobalSignalNumbers.h:
  Auto merged
ndb/src/kernel/blocks/dbdict/Dbdict.cpp:
  Auto merged
ndb/src/kernel/blocks/dbdict/Dbdict.hpp:
  Auto merged
ndb/src/kernel/blocks/dbdih/DbdihMain.cpp:
  Auto merged
ndb/src/ndbapi/ndberror.c:
  Auto merged

into  zippy.(none):/home/cmiller/work/mysql/merge/mysql-5.1


libmysqld/lib_sql.cc:
  Auto merged
libmysqld/libmysqld.c:
  Auto merged
mysql-test/mysql-test-run.sh:
  Auto merged
mysql-test/r/gis.result:
  Auto merged
mysql-test/r/information_schema.result:
  Auto merged
mysql-test/r/sp-security.result:
  Auto merged
mysql-test/r/variables.result:
  Auto merged
mysql-test/t/gis.test:
  Auto merged
mysql-test/t/sp-security.test:
  Auto merged
mysql-test/t/variables.test:
  Auto merged
scripts/make_binary_distribution.sh:
  Auto merged
sql/ha_ndbcluster.cc:
  Auto merged
sql/item_geofunc.h:
  Auto merged
sql-common/client.c:
  Auto merged
sql/set_var.cc:
  Auto merged
sql/sql_acl.cc:
  Auto merged
sql/sql_parse.cc:
  Auto merged
storage/ndb/include/kernel/GlobalSignalNumbers.h:
  Auto merged
storage/ndb/src/kernel/blocks/dbdict/Dbdict.cpp:
  Auto merged
storage/ndb/src/kernel/blocks/dbdict/Dbdict.hpp:
  Auto merged
mysql-test/t/mysqldump.test:
  Manual merge.  (Seems to need null-merging.)
sql/mysqld.cc:
  Manual merge + formatting change.
sql/sql_show.cc:
  Manual merge

into  andrepl.(none):/home/elkin/MySQL/TEAM/FIXES/5.1/20919_temp_nlog


mysql-test/t/rpl_openssl.test:
  Auto merged
sql/ha_ndbcluster.cc:
  Auto merged
sql/sql_base.cc:
  Auto merged

We now reset the THD members related to auto_increment+binlog in
MYSQL_LOG::write(). This is better than in THD::cleanup_after_query(),
which was not able to distinguish between SELECT myfunc1(),myfunc2()
and INSERT INTO t SELECT myfunc1(),myfunc2() from a binlogging point
of view.
Rows_log_event::exec_event() now calls lex_start() instead of
mysql_init_query() because the latter now does too much (it resets
the binlog format).


mysql-test/extra/rpl_tests/rpl_insert_id.test:
  fix after merge
mysql-test/mysql-test-run.pl:
  -v does not bring useful information when running valgrind; I remove it;
  if you think it's useful add it back.
mysql-test/r/binlog_stm_mix_innodb_myisam.result:
  Position columns of SHOW BINLOG EVENTS are replaced by # (more robust
  if the size of an event changes).
mysql-test/r/rpl_insert_id.result:
  fix after merge
mysql-test/r/rpl_loaddata.result:
  The binlog positions change, because one event disappeared; indeed there
  was this in the binlog (in the current 5.1!):
  SET INSERT_ID=2;
  SET INSERT_ID=1;
  SET TIMESTAMP=1152540671;
  load data LOCAL INFILE '/tmp/SQL_LOAD_MB-1-2' INTO table t1;
  Two INSERT_ID events, useless and a bug. Goes away afer cleaning up
  auto_increment handling.
mysql-test/r/rpl_switch_stm_row_mixed.result:
  INSERT_ID=5 appears, it's a consequence of having merged the fix
  for BUG#20341
  "stored function inserting into one auto_increment puts bad data in slave".
  In mixed mode, if one substatement of a stored procedure requires row-based,
  the entire procedure uses row-based (was already true for stored functions);
  this is a consequence of not doing the resetting of binlog format inside
  lock_tables() (which didn't work with how the slave thread executes
  row-based binlog events).
mysql-test/t/rpl_switch_stm_row_mixed.test:
  removing the multi-row delayed insert because in RBR the number of events
  which it generates, is not repeatable (probably depends on how the delayed
  thread groups rows, i.e. dependent on timing).
sql/ha_partition.cc:
  update to new prototype
sql/ha_partition.h:
  update to new prototype of the handler:: method.
sql/handler.cc:
  after-merge fixes (manually merging part which was hard to merge in fmtool)
sql/log.cc:
  When we write to the binary log, THD's parameters which influenced this
  write are reset: stmt_depends_on_first_successful_insert_id_in_prev_stmt
  and auto_inc_intervals_in_cur_stmt_for_binlog. This is so that future
  writes are not influenced by those and can write their own values.
  As a consequence, when we don't write to the binlog we do not reset.
  This is to abide by the rule that in a complex statement (using triggers etc),
  the first top- or substatement to generate auto_increment ids
  wins their writing to the binlog (that writing may be done by the statement
  itself or by the caller); so for example for
  INSERT INTO t SELECT myfunc() where myfunc() inserts into auto_increment
  and INSERT INTO t does not, myfunc() will fill
  auto_inc_intervals_in_cur_stmt_for_binlog, which will not be reset when
  myfunc() ends, then INSERT INTO t will write to the binlog and thus
  write the preserved auto_inc_intervals_in_cur_stmt_for_binlog.
sql/log_event.cc:
  mysql_init_query() does too much now to be called in Rows_log_event::exec_event
  (it call mysql_reset_thd_for_next_command() which may switch
  the binlog format now).
  It's ok to call it in Table_map_log_event::exec_event() but its call must
  be before setting the binlog format to "row".
sql/sql_base.cc:
  Resetting the binlog format in lock_tables() was a bad idea of mine;
  it causes problems in execution of row-based binlog events, where
  the thread sets the binlog format by itself and does not want a next
  lock_tables() to reset the binlog format.
  It is also misleading, for a function named lock_tables(), to reset
  the binlog format.
  As a consequence of this change, in mixed binlogging mode, a routine
  is logged either entirely statement-based or entirely row-based, we
  don't switch in the middle (this was already true for prelocked routines,
  now it's also true for stored procedures).
sql/sql_class.cc:
  resetting of auto_increment variables used for binlogging is now done
  when writing to the binary log, no need to do the resetting at the end
  of the statement. It is also more correct this way; consider
  SELECT myfunc1(),myfunc2();
  where both functions insert into the same auto_increment column.
  Binlogging is done in 2 events: "SELECT myfunc1()" and "SELECT myfunc2()".
  So each of those needs to have, in binlog, the INSERT_ID which
  it inserted. But as the 2 function calls are executed under prelocked mode,
  the old code didn't reset auto_inc_intervals_in_cur_stmt_for_binlog
  after the first SELECT was binlogged, and so the INSERT_ID of the first
  SELECT was binlogged for the first SELECT and (wrong) also for the 2nd
  SELECT event.
  stmt_depends_on_first_... has the same logic.
sql/sql_class.h:
  clearer comment
sql/sql_delete.cc:
  unneeded #ifdef. As we temporarily change the binlog format to "statement"
  before calling mysql_delete(), we must restore it afterwards.
sql/sql_insert.cc:
  after-merge fixes.
  No need to reset auto_inc_intervals_in_cur_stmt_for_binlog for every
  row in the delayed insert system thread, because we already reset it
  when writing to the binlog.
sql/sql_parse.cc:
  unneeded #ifdef

into  andrepl.(none):/home/elkin/MySQL/TEAM/FIXES/5.1/20919_temp_nlog


mysql-test/t/rpl_openssl.test:
  Auto merged
sql/ha_ndbcluster.cc:
  Auto merged
sql/sql_base.cc:
  manual merge

into  gbichot3.local:/home/mysql_src/mysql-5.0

storage/ndb/src/kernel/blocks/dblqh/DblqhMain.cpp:
  dont mess up signal log, also changed w+ to a

into  orca.ndb.mysql.com:/space_old/pekka/ndb/version/my51-bug18781


storage/ndb/src/kernel/blocks/dbdict/DictLock.txt:
  SCCS merged
storage/ndb/src/kernel/blocks/dbdih/Dbdih.hpp:
  manual
storage/ndb/src/kernel/blocks/dbdih/DbdihMain.cpp:
  SCCS merged
storage/ndb/src/kernel/vm/SimulatedBlock.cpp:
  manual
storage/ndb/src/kernel/vm/SimulatedBlock.hpp:
  manual
storage/ndb/test/run-test/daily-basic-tests.txt:
  SCCS merged

ndb/src/kernel/blocks/dbdict/DictLock.txt:
  wait until SL_STARTED before sending DICT_UNLOCK_ORD
ndb/src/kernel/blocks/dbdih/Dbdih.hpp:
  wait until SL_STARTED before sending DICT_UNLOCK_ORD
ndb/src/kernel/blocks/dbdih/DbdihMain.cpp:
  wait until SL_STARTED before sending DICT_UNLOCK_ORD
ndb/src/kernel/vm/SimulatedBlock.cpp:
  wait until SL_STARTED before sending DICT_UNLOCK_ORD
ndb/src/kernel/vm/SimulatedBlock.hpp:
  wait until SL_STARTED before sending DICT_UNLOCK_ORD
ndb/test/run-test/daily-basic-tests.txt:
  wait until SL_STARTED before sending DICT_UNLOCK_ORD

into  orca.ndb.mysql.com:/space_old/pekka/ndb/version/my51-bug18781


storage/ndb/include/kernel/GlobalSignalNumbers.h:
  auto
storage/ndb/src/common/debugger/signaldata/SignalNames.cpp:
  SCCS merged
storage/ndb/src/kernel/blocks/ndbcntr/NdbcntrMain.cpp:
  auto
storage/ndb/src/kernel/vm/SimulatedBlock.cpp:
  auto
storage/ndb/src/kernel/vm/SimulatedBlock.hpp:
  manual

ndb/include/kernel/GlobalSignalNumbers.h:
  5.0 : add NODE_START_REP from 5.1
ndb/src/common/debugger/signaldata/SignalNames.cpp:
  5.0 : add NODE_START_REP from 5.1
ndb/src/kernel/blocks/ndbcntr/NdbcntrMain.cpp:
  5.0 : add NODE_START_REP from 5.1
ndb/src/kernel/vm/SimulatedBlock.cpp:
  5.0 : add NODE_START_REP from 5.1
ndb/src/kernel/vm/SimulatedBlock.hpp:
  5.0 : add NODE_START_REP from 5.1

into  gbichot3.local:/home/mysql_src/mysql-5.1


mysql-test/mysql-test-run.pl:
  Auto merged
sql/sql_base.cc:
  Auto merged

into  romeo.(none):/home/bk/b20821-mysql-5.1-new-rpl

into  chilla.local:/home/mydev/mysql-5.1-aid


sql/ha_federated.cc:
  Auto merged

into  dsl-hkigw8-feb1fb00-100.dhcp.inet.fi:/usr_rh9/home/elkin.rh9/MySQL/TEAM/FIXES/5.0/20919_temp_nlog


sql/sql_base.cc:
  Manual merge

set properly.

closing temp tables through end_thread
had a flaw in binlog-off branch of close_temporary_tables where
next table to close was reset via table->next
 for (table= thd->temporary_tables; table; table= table->next)
which was wrong since the current table instance got destoyed at
	close_temporary(table, 1);

The fix adapts binlog-on branch method to engage the loop's internal 'next' variable which holds table->next prior table's destoying.



sql/sql_base.cc:
  no-binlog branch is fixed: scanning across temporary_tables must be careful to save next table since the current is being destroyed inside of close_temporary. 
  binlog-is-open case is ok.

into  gbichot3.local:/home/mysql_src/mysql-5.1


sql/ha_federated.cc:
  Auto merged
sql/ha_ndbcluster.cc:
  Auto merged
sql/handler.h:
  Auto merged
sql/log_event.cc:
  Auto merged
sql/set_var.cc:
  Auto merged
sql/sql_class.cc:
  Auto merged
sql/sql_class.h:
  Auto merged
sql/sql_parse.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/sql_table.cc:
  Auto merged
sql/sql_update.cc:
  Auto merged
sql/handler.cc:
  will fix by hand
mysql-test/extra/rpl_tests/rpl_insert_id.test:
  merge
mysql-test/r/rpl_insert_id.result:
  merge
sql/sql_insert.cc:
  merge

mysql-test/r/rpl_switch_stm_row_mixed.result:
  post-merge fix
mysql-test/t/rpl_switch_stm_row_mixed.test:
  post-merge fix (and no need to use a table t12 in some place).

into  gbichot3.local:/home/mysql_src/mysql-5.1


mysql-test/t/disabled.def:
  Auto merged
sql/set_var.cc:
  Auto merged
sql/sql_class.h:
  Auto merged
mysql-test/r/rpl_switch_stm_row_mixed.result:
  manual merge (will fix)
mysql-test/t/rpl_switch_stm_row_mixed.test:
  manual merge (will fix)

mysql-test/extra/binlog_tests/mix_innodb_myisam_binlog.test:
  As in other tests, we should replace both position columns of SHOW BINLOG
  EVENTS; otherwise a small change (like here, the fact that CREATE TEMPORARY
  TABLE is not binlogged in RBR as a consequence of the bugfix for BUG#20522)
  causes a large diff in the result file.
mysql-test/r/binlog_row_mix_innodb_myisam.result:
  result update: positions in SHOW BINLOG EVENTS become #, and
  the CREATE TEMPORARY TABLE disappear from binlog (consequence of fix for
  BUG#20522 "RBR: CREATE TEMPORARY TABLE SELECT writes to binlog though
  unneeded").

mysql-test/r/rpl_switch_stm_row_mixed.result:
  result update.
  I noticed the appearance of an additional table_map+rows in the binlog
  when INSERT DELAYED, since I pulled the latest fixes to RBR of 
  INSERT DELAYED. This is ok, I put the reason why into sql_insert.cc.
sql/sql_insert.cc:
  A comment about the new row-based binlogging of INSERT DELAYED.
  Removing duplicate MY_HOOKS (from a wrong merge of the past??).

into  gbichot3.local:/home/mysql_src/mysql-5.1


sql/sql_insert.cc:
  Auto merged

were copied/split between 5.0 and 5.1).


mysql-test/extra/rpl_tests/rpl_auto_increment.test:
  manual merge of test from 5.0
mysql-test/extra/rpl_tests/rpl_insert_id.test:
  manuel merge of test from 5.0
mysql-test/r/rpl_auto_increment.result:
  error messages changed compared to 5.0

into  gbichot3.local:/home/mysql_src/mysql-5.1


mysql-test/r/rpl_auto_increment.result:
  Auto merged
mysql-test/r/rpl_insert_id.result:
  Auto merged
mysql-test/t/rpl_openssl.test:
  Auto merged
sql/ha_ndbcluster.cc:
  Auto merged
mysql-test/t/rpl_auto_increment.test:
  will fix by hand
mysql-test/t/rpl_insert_id.test:
  will fix by hand
sql/handler.cc:
  comment
sql/handler.h:
  manual merge
sql/sql_insert.cc:
  manual merge

this is a cleanup patch for our current auto_increment handling:
new names for auto_increment variables in THD, new methods to manipulate them
(see sql_class.h), some move into handler::, causing less backup/restore
work when executing substatements. 
This makes the logic hopefully clearer, less work is is needed in
mysql_insert().
By cleaning up, using different variables for different purposes (instead
of one for 3 things...), we fix those bugs, which someone may want to fix
in 5.0 too:
BUG#20339 "stored procedure using LAST_INSERT_ID() does not replicate
statement-based"
BUG#20341 "stored function inserting into one auto_increment puts bad
data in slave"
BUG#19243 "wrong LAST_INSERT_ID() after ON DUPLICATE KEY UPDATE"
(now if a row is updated, LAST_INSERT_ID() will return its id)
and re-fixes:
BUG#6880 "LAST_INSERT_ID() value changes during multi-row INSERT"
(already fixed differently by Ramil in 4.1)
Test of documented behaviour of mysql_insert_id() (there was no test).
The behaviour changes introduced are:
- LAST_INSERT_ID() now returns "the first autogenerated auto_increment value
successfully inserted", instead of "the first autogenerated auto_increment
value if any row was successfully inserted", see auto_increment.test.
Same for mysql_insert_id(), see mysql_client_test.c.
- LAST_INSERT_ID() returns the id of the updated row if ON DUPLICATE KEY
UPDATE, see auto_increment.test. Same for mysql_insert_id(), see
mysql_client_test.c.
- LAST_INSERT_ID() does not change if no autogenerated value was successfully 
inserted (it used to then be 0), see auto_increment.test.
- if in INSERT SELECT no autogenerated value was successfully inserted,
mysql_insert_id() now returns the id of the last inserted row (it already
did this for INSERT VALUES), see mysql_client_test.c.
- if INSERT SELECT uses LAST_INSERT_ID(X), mysql_insert_id() now returns X
(it already did this for INSERT VALUES), see mysql_client_test.c.
- NDB now behaves like other engines wrt SET INSERT_ID: with INSERT IGNORE,
the id passed in SET INSERT_ID is re-used until a row succeeds; SET INSERT_ID
influences not only the first row now.

Additionally, when unlocking a table we check that the thread is not keeping
a next_insert_id (as the table is unlocked that id is potentially out-of-date);
forgetting about this next_insert_id is done in a new
handler::ha_release_auto_increment().

Finally we prepare for engines capable of reserving finite-length intervals
of auto_increment values: we store such intervals in THD. The next step
(to be done by the replication team in 5.1) is to read those intervals from
THD and actually store them in the statement-based binary log. NDB
will be a good engine to test that.


mysql-test/extra/binlog_tests/binlog.test:
  Testing that if INSERT_ID is set to a value too big for the
  column's type, the binlogged INSERT_ID is the truncated value
  (important if slave has a column of a "wider" numeric type).
  Testing binlogging of INSERT_ID with INSERT DELAYED, to be sure that 
  we binlog an INSERT_ID event only for the delayed rows which use one.
mysql-test/extra/rpl_tests/rpl_insert_id.test:
  Testcase for BUG#20339 "stored procedure using
  LAST_INSERT_ID() does not replicate statement-based".
  Testcase for BUG#20341 "stored function inserting into one
  auto_increment puts bad data in slave".
mysql-test/extra/rpl_tests/rpl_loaddata.test:
  Test that LOAD DATA INFILE sets a value for a future LAST_INSERT_ID().
mysql-test/r/auto_increment.result:
  behaviour change: when INSERT totally fails (not even succeeds
  partially and then rolls back), don't change last_insert_id().
  Behaviour change: LAST_INSERT_ID() is now the first successfully inserted,
  autogenerated, id.
  Behaviour change: if INSERT ON DUPLICATE KEY UPDATE, if the table has auto_increment
  and a row is updated, then LAST_INSERT_ID() returns the id of this row.
mysql-test/r/binlog_row_binlog.result:
  result update
mysql-test/r/binlog_stm_binlog.result:
  result update
mysql-test/r/insert.result:
  result update
mysql-test/r/rpl_insert_id.result:
  result update
mysql-test/r/rpl_loaddata.result:
  result update
mysql-test/r/rpl_ndb_auto_inc.result:
  ndb's behaviour is now like other engines wrt SET INSERT_ID
  in a multi-row INSERT:
  - with INSERT IGNORE: the id passed in SET INSERT_ID is re-used until
  a row succeeds.
  - generally, SET INSERT_ID sets the first value and other values are
  simply computed from this first value, instead of previously where
  the 2nd and subsequent values where not influenced by SET INSERT_ID;
  this good change is due to the removal of "thd->next_insert_id=0"
  from ha_ndbcluster.
mysql-test/t/auto_increment.test:
  A testcase of BUG#19243: if ON DUPLICATE KEY UPDATE updates a row,
  LAST_INSERT_ID() now returns the id of the row.
  Test of new behaviour of last_insert_id() when no autogenerated value was
  inserted, or when only some autogenerated value (not the first of them) was
  inserted.
mysql-test/t/insert.test:
  testing INSERT IGNORE re-using generated values
sql/ha_federated.cc:
  update for new variables.
sql/ha_ndbcluster.cc:
  handler::auto_increment_column_changed not needed, equivalent to
  (insert_id_for_cur_row > 0).
  thd->next_insert_id=0 not needed anymore; it was used to force
  handler::update_auto_increment() to call ha_ndbcluster::get_auto_increment()
  for each row of a multi-row INSERT, now this happens naturally
  because NDB says "I have reserved you *one* value" in get_auto_increment(),
  so handler::update_auto_increment() calls again for next row.
sql/handler.cc:
  More comments, use of new methods and variables. Hopes to be clearer
  than current code.
  thd->prev_insert_id not in THD anymore: it is managed locally by inserters
  (like mysql_insert()).
  THD::clear_next_insert_id is now equivalent to
  handler::next_insert_id > 0.
  get_auto_increment() reserves an interval of values from the engine,
  uses this interval for next rows of the statement, until interval
  is exhausted then it asks for another interval (of a bigger size
  than the first one; size doubles until reaching 65535 then it stays constant).
  If doing statement-based binlogging, intervals are remembered in a list
  for storage in the binlog.
  For "forced" insert_id values (SET INSERT_ID or replication slave),
  forced_auto_inc_intervals is non-empty and the handler takes its intervals
  from there, without calling get_auto_increment().
  ha_release_auto_increment() resets the handler's auto_increment variables;
  it calls release_auto_increment() which is handler-dependent and
  serves to return to the engine any unused tail of the last used
  interval.
  If ending a statement, next_insert_id>0 means that autoinc values have been
  generated or taken from the master's binlog (in a replication slave) so
  we clear those values read from binlog, so that next top- or sub-
  statement does not use them.
sql/handler.h:
  handler::auto_increment_changed can be replaced by
  (handler::insert_id_for_cur_row > 0).
  THD::next_insert_id moves into handler (more natural, and prepares
  for the day when we'll support a single statement inserting into
  two tables - "multi-table INSERT" like we have UPDATE - will this
  happen?).
  This move makes the backup/restore of THD::next_insert_id when entering
  a substatement unneeded, as each substatement has its own handler
  objects.
sql/item_func.cc:
  new names for variables.
  For the setting of what mysql_insert_id() will return to the client,
  LAST_INSERT_ID(X) used to simply pretend that the generated autoinc
  value for the current row was X, but this led to having no reliable
  way to know the really generated value, so we now have a bool:
  thd->arg_of_last_insert_id_function which enables us to know that
  LAST_INSERT_ID(X) was called (and then X can be found in
  thd->first_successful_insert_id_in_prev_stmt).
sql/log.cc:
  new variable names for insert_ids. Removing some unused variables in the slow
  log.
sql/log_event.cc:
  new variable names, comments. Preparing for when master's won't binlog
  LAST_INSERT_ID if it was 0.
sql/set_var.cc:
  new variable names.
  The last change repeats how Bar fixed BUG#20392
  "INSERT_ID session variable has weird value" in 5.0.
sql/sql_class.cc:
  new variables for insert_id. In THD::cleanup_after_query() we fix
  BUG#20339 "stored procedure using LAST_INSERT_ID() does not replicate
  statement-based" (will one want to fix it in 5.0?). Many comments
  about what stored functions do to auto_increment.
  In reset|restore_sub_statement_state(), we need to backup less
  auto_inc variables as some of them have moved to the handler;
  we backup/restore those which are about the current top- or sub-
  statement, *not* those about the statement-based binlog
  (which evolve as the top- and sub-statement execute).
  Because we split THD::last_insert_id into 
  THD::first_successful_insert_id_in_prev_stmt and
  THD::auto_inc_intervals_for_binlog (among others), we fix
  BUG#20341 "stored function inserting into one auto_increment
  puts bad data in slave": indeed we can afford to not backup/restore
  THD::auto_inc_intervals_for_binlog (which fixes the bug) while still
  backing up / restoring THD::first_successful_insert_id_in_prev_stmt
  (ensuring that the top-level LAST_INSERT_ID() is not affected by INSERTs
  done by sub-statements, as is desirable and tested in rpl_insert_id.test).
sql/sql_class.h:
  new variables and methods for auto_increment.
  Some THD members move into handler (those which are really about
  the table being inserted), some stay in THD (those which are
  about what a future LAST_INSERT_ID() should return, or about
  what should be stored into the statement-based binlog).
  THD::next_insert_id moves to handler::.
  THD::clear_next_insert_id removed (had become equivalent
  to next_insert_id > 0).
  THD::last_insert_id becomes four:
  THD::first_successful_insert_id_in_cur_stmt,
  THD::auto_inc_intervals_for_binlog,
  handler::insert_id_for_cur_row,
  THD::first_successful_insert_id_in_prev_stmt.
  THD::current_insert_id becomes:
  THD::first_successful_insert_id_in_prev_stmt_for_binlog
  THD::prev_insert_id is removed, handler can just use
  handler::insert_id_for_cur_row instead (which is more accurate:
  for the first row, prev_insert_id was set before get_auto_increment
  was called, so was 0, causing a call to
  get_auto_increment() for the 2nd row if the 1st row fails;
  here we don't need the call as insert_id_for_cur_row has
  the value of the first row).
  THD::last_insert_id_used becomes: stmt_depends_on_first_row_in_prev_stmt
  THD::insert_id_used is removed (equivalent to
  auto_inc_intervals_for_binlog non empty).
  The interval returned by get_auto_increment() and currently being
  consumed is handler::auto_inc_interval_for_cur_row.
  Comments to explain each of them.
  select_insert::last_insert_id becomes autoinc_value_of_last_inserted_row.
sql/sql_insert.cc:
  the "id" variable is not changed for each row now; it used to compensate for
  this contradiction:
  - thd->last_insert_id supposed job was to keep the id of the first row
  - but it was updated for every row
  - so mysql_insert() made sure to catch its first value and restore it at the end of stmt.
  Now THD keeps the first value in first_successful_insert_id_in_cur_stmt,
  and value of the row in insert_id_for_cur_row. So "id" only serves to fill
  mysql_insert_id(), as depending on some conditions, "id" must be different
  values.
  Prev_insert_id moves from THD to write_record().
  We now set LAST_INSERT_ID() in ON DUPLICATE KEY UPDATE too (BUG#19243).
  In an INSERT DELAYED, we still "reset auto-increment caching" but differently
  (by calling ha_release_auto_increment()).
sql/sql_load.cc:
  no need to fiddle with "id", THD maintains
  THD::first_successful_insert_id_in_cur_stmt by itself and correctly now.
  ha_release_auto_increment() is now (logically) called before we unlock
  the table.
sql/sql_parse.cc:
  update to new variable names.
  Assertion that reset_thd_for_next_command() is not called for every
  substatement of a routine (I'm not against it, but if we do this change,
  statement-based binlogging needs some adjustments).
sql/sql_select.cc:
  update for new variable names
sql/sql_table.cc:
  next_insert_id not needed in mysql_alter_table(), THD manages.
sql/sql_update.cc:
  update for new variable names.
  Even though this is UPDATE, an insert id can be generated (by
  LAST_INSERT_ID(X)) and should be recorded because mysql_insert_id() wants
  to know about it.
sql/structs.h:
  A class for "discrete" intervals (intervals of integer numbers with a certain
  increment between them): Discrete_interval, and a class for a list of such
  intervals: Discrete_intervals_list
tests/mysql_client_test.c:
  tests of behaviour of mysql_insert_id(): there were no such tests, while in
  our manual we document its behaviour. In comments you'll notice the behaviour
  changes introduced (there are 5).