The bug was that if the server was running in mixed binlogging mode,
and an INSERT DELAYED used some needing-row-based components like UUID(),
the server didn't binlog this row-based but statement-based, which
thus failed to insert correct data on the slave.
This changeset implements that when a delayed_insert thread is created,
if the server's global binlog mode is "mixed", that thread will use row-based.
This also fixes BUG#20633 "INSERT DELAYED RAND() or @user_var does not
replicate statement-based": we don't fix it in statement-based mode (would
require bookeeping of rand seeds and user variables used by each row),
but at least it will now work in mixed mode (as row-based will be used).
We re-enable rpl_switch_stm_row_mixed.test (so BUG#18590
which was about re-enabling this test, will be closed) to test the fixes.
Between when it was disabled and now, some good changes to row-based
binlogging (no generation of table map events for non-changed tables)
induce changes in the test's result file.


mysql-test/r/rpl_switch_stm_row_mixed.result:
  result update.
  Note that some pieces of binlog are gone, not due to my test but to changes
  to the row-based binlogging code (non-changed tables don't generate
  table map binlog events now) done while the test was disabled.
mysql-test/t/disabled.def:
  this test works now
mysql-test/t/rpl_switch_stm_row_mixed.test:
  testing fix to make INSERT DELAYED work in mixed mode
sql/sql_insert.cc:
  In mixed binlogging mode, the delayed_insert system thread now always
  uses row-based binlogging.
  This makes replication of INSERT DELAYED VALUES(RAND()) or VALUES(@A)
  work in mixed mode (it does not in statement-based).