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