For tables with metadata sizes ranging from 251 to 255 the size
of the event data (m_data_size) was being improperly calculated
in the Table_map_log_event constructor. This was due to the fact
that when writing the Table_map_log_event body (in
Table_map_log_event::write_data_body) a call to net_store_length
is made for packing the m_field_metadata_size. It happens that
net_store_length uses *one* byte for storing
m_field_metadata_size when it is smaller than 251 but *three*
bytes when it exceeds that value. BUG 42749 had already
pinpointed and fix this fact, but the fix was incomplete, as the
calculation in the Table_map_log_event constructor considers 255
instead of 251 as the threshold to increment m_data_size by
three. Thence, the window for having a mismatch between the
number of bytes written and the number of bytes accounted in the
event length (m_data_size) was left open for
m_field_metadata_size values between 251 and 255.

We fix this by changing the condition in the Table_map_log_event
constructor to match the one in the net_store_length, ie,
increment one byte if m_field_metadata_size < 251 and three if it
exceeds this value.

mysql-test/suite/rpl/r/rpl_row_tbl_metadata.result:
  Updated result file.
mysql-test/suite/rpl/t/rpl_row_tbl_metadata.test:
  Changes to the original test case: added slave and moved
  file into the rpl suite.
  
  New test case: replicates two tables one with 250 and 
  another with 252 metadata sizes. This exercises the usage
  of 1 or 3 bytes while packing the m_field_metadata_size.
sql/log_event.cc:
  Made the m_data_size calculation for the table map log event
  to match the number of bytes used while packing the 
  m_field_metadata_size value (according to net_store_length
  function in pack.c).