Problem: when SHOW BINLOG EVENTS was issued, it increased the value of
@@session.max_allowed_packet. This allowed a non-root user to increase
the amount of memory used by her thread arbitrarily. Thus, it removes
the bound on the amount of system resources used by a client, so it
presents a security risk (DoS attack).

Fix: it is correct to increase the value of @@session.max_allowed_packet
while executing SHOW BINLOG EVENTS (see BUG 30435). However, the
increase should only be temporary. Thus, the fix is to restore the value
when SHOW BINLOG EVENTS ends.
The value of @@session.max_allowed_packet is also increased in
mysql_binlog_send (i.e., the binlog dump thread). It is not clear if this
can cause any trouble, since normally the client that issues
COM_BINLOG_DUMP will not issue any other commands that would be affected
by the increased value of @@session.max_allowed_packet. However, we
restore the value just in case.


mysql-test/suite/rpl/r/rpl_packet.result:
  update result file
mysql-test/suite/rpl/t/rpl_packet.test:
  Add test that verifies that @@session.max_allowed_packet does not change
  when issuing SHOW BINLOG EVENTS.
  Make previous sub-test clean up.
  Add comments listing the bugs in this test case.
sql/sql_repl.cc:
  Restore the old value of thd->variables.max_allowed_packet at the
  end of mysql_binlog_send and mysql_show_binlog_events.