Initial implementation of max_binlog_packet.patch

The problem solved by the patch is that the limit set by
max_allowed_packet does not work well with row-based replication. Even
if it is not possible to INSERT/UPDATE values larger than the limit set
by max_allowed_packet, the limit may still be exceeded when shipping the
binary log due to the fact that for each modified row there may be one
or two full row images in the binary log. So, for example, for a table
with a BLOB column, even if only an INT column is changed, there will be
one or two BLOB images stored into the corresponding RBR event, so it
may break replication by exceeding the max_allowed_packet limit on
either master or slave.

A similar problem exists when replaying the binary log with mysqlbinlog,
but in this case the base64 overhead is added on top of it.

max_binlog_packet.patch addresses both problems by introducing the
max_binlog_packet system variable. The variable's semantics is quite
different depending whether it is used in the global or a session scope:

- The global max_binlog_packet value, when it is not 0, represents an
  effective packet size limit for binary log operations on both the
  master and slaves. i.e. reading a binlog event from the binary log on
  the master, sending it to a slave, reading it by a slave, and reading
  it from the relay log by the slave are all performed with the
  effective max_allowed_packet value equal to "max_binlog_packet + RBR
  event header length" regardless of the actual value of
  max_allowed_packet.

  The default value for max_binlog_packet is zero (i.e. the real value
  of max_allowed_packet will be used in all contexts).

  Unlike most other variables, the client's session max_binlog_packet
  value is NOT initialized from the global max_binlog_packet value. When
  a new client connects, its max_binlog_packet session variable is set
  to 0 regardless of the global variable value.

- The session max_binlog_packet variable can only be set by users with
  the SUPER privilege. Once it is set to a non-zero value, it changes
  the effective value of max_allowed_packet for the current session so
  that the BINLOG event corresponding to an event at most
  max_binlog_packet bytes long could be read by the server, that is:

  the effective max_allowed_packet = (session's max_binlog_event + event
  header length) * 4 / 3

  where the 4/3 multiplier is the base64 overhead.
  

The session max_binlog_packet variable is used by mysqlbinlog which now
has a new command line option with the same name. When passed on the
command line, --max-binlog-packet makes mysqlbinlog to prepend it's
output with "SET LOCAL max_binlog_packet=<option value>;".

In other words, max_binlog_packet allows to define a limit on the
maximum possible RBR event for both replication and binlog
rollforwarding independently from max_allowed_packet.