binlog even if they changed nothing, and a test for this.
This is useful when users use these commands to clean up their master and slave by issuing
one command on master (assume master and slave have slightly different data for some
reason and you want to clean up both).
Note that I have not changed multi-table DELETE and multi-table UPDATE because their
error-reporting mechanism is more complicated.


mysql-test/r/mysqlbinlog.result:
  result update
mysql-test/r/rpl_charset.result:
  result update
mysql-test/r/rpl_flush_log_loop.result:
  result update
mysql-test/r/rpl_replicate_do.result:
  result update
mysql-test/r/rpl_temporary.result:
  result update
mysql-test/t/mysqlbinlog.test:
  moving SET TIMESTAMP up as DROP shows up in binlog
sql/sql_db.cc:
  DROP DATABASE IF EXISTS is now always logged to binlog, even if db did not exist
sql/sql_delete.cc:
  DELETE FROM t is now always logged to binlog even if no rows deleted (but in this case, only if really no error).
sql/sql_table.cc:
  DROP TABLE IF EXISTS is now always logged to binlog even if table did not exist
sql/sql_update.cc:
  UPDATE is now always logged to binlog even if no rows updated (but in this case, only if really no error).