WL#5778: Binary log interface

This is a step towards making replication a library, such that the 5.6 rpl-lib can 
be plugged into the 5.5 core [WL#5675].

In this worklog, we define an interface for the binary log. We only create a class 
that groups together the functions that the core server needs in order to write to 
the binary log and to execute related SQL commands. The interface will contain all 
functions we need, but the function prototypes will not be in their final form. In 
particular, unstable structs such as THD will be passed as parameters. In future 
worklogs, we will change the function prototypes.

We create the class Binlog. Eventually, Binlog will replace MYSQL_BIN_LOG, but 
for now we will use MYSQL_BIN_LOG as the backend for the Binlog interface. The 
class Binlog has the following fields:

is_enabled: Return true if binary logging is enabled.

log_statement: Write a statement to the binary log.

log_write_row: Write a Write_row event to the binary log.

log_update_row: Write an Update_row event to the binary log.

log_delete_row: Write a Delete_row event to the binary log.

log_loaded_block: Write a block of data loaded by LOAD DATA to the binary log.

flush_binary_log: Execute FLUSH BINARY LOG command.

show_binary_logs: Execute SHOW BINARY LOGS command.

show_binlog_events: Execute SHOW BINLOG EVENTS command.

purge_binary_logs: Execute PURGE BINARY LOGS command.

purge_binary_logs_before: Execute PURGE BINARY LOGS BEFORE command.

show_master_status: Execute SHOW MASTER STATUS command.

reset_master: Execute RESET MASTER command.

after_lock_tables: Execute binlog-specific functionality after tables have been 
locked. This should do what decide_logging_format does now.
Note: core should still mark some statements unsafe, e.g., in the parser.

==== Open questions ====

1. The following was removed from the original worklog because the purpose
   was unclear:

   "class Delayed_row_binlog_data is used to store information related to rows
   generated by INSERT DELAYED. This is required to support the rows query log
   event for INSERT DELAYED."
   
   "bool thd_get_binlog_rows_query_log_events(THD *thd);"

   Questions: what are these needed for? Who creates Delayed_row_binlog_data
   objects (core or rpl-lib)? Should thd_get_binlog_rows_query_log_events be
   defined in core or in rpl-lib?

Binlog
======

class Binlog {
public:
  int is_enabled();
  [ TODO: determine args for log_statement /Sven]
  int log_statement(...);
  int log_write_row(TABLE* table, const uchar* record);
  int log_update_row(TABLE* table, const uchar* before_record,
                     const uchar* after_record);
  int log_delete_row(TABLE* table, const uchar* record);
  int log_loaded_block(IO_CACHE *io_cache);
  int flush_binary_log(THD* thd);
  int purge_binary_logs(THD* thd, const char* to_log);
  int purge_binary_logs_before(THD* thd, time_t before_time);
  int reset_master(THD* thd);
  int show_binary_logs(THD* thd);
  int show_binlog_events(THD* thd);
  int show_master_status(THD* thd);

  [Q: how is the method below used? /sven]
  int get_delayed_row_data(THD* thd, TABLE* table,
                           void** row_binlog_data,
                           LEX_STRING* query, bool log_on);

  [Q: what are the methods below used for? they are not described in the hls.
   /sven]
  int before_handle_delayed_row(THD* thd, TABLE* table,
                                void* row_binlog_data,
                                LEX_STRING* query, bool log_query);
  int after_handle_delayed_row(THD* thd, TABLE* table,
                               void* row_binlog_data,
                               LEX_STRING* query, bool log_query);
}