WL#1126: Handle gracefully long packets when using compressed protocol

Affects: Server-4.1   —   Status: Un-Assigned

This is to fix the problem described in BUG#1011:

The idea is that the client should get 'ER_NET_PACKET_TOO_LARGE' when
sending a long packet to the mysqld server.  Currently it only works
when using the normal (not compressed) protocol.

When fixing this, one should be careful to only remove the logical
packet that was too long, not any other packets. In other words, we
can't just do a vio_read until there is no more data to get.

The problem with removing the packet is that a compressed packet may
include several normal packets.  In other words, we have to uncompress
data to read the real packet headers.

The only file that needs to be changed is sql/net_serv.cc.

One can test this by running 'perl tests/big_record.pl --compress'
against a myslqd server started with --max_packet_length=8192 One
should only get 'ER_NET_PACKET_TOO_LARGE' errors from the server, no
'server has gone away' errors.  (One has to change the big_record.pl
program slightly to ignore the above error).

Proposed way to fix this:

- Change net_realloc() to create a packet of up to
  '16*1024*1024+NET_HEADER_SIZE + COMP_HEADER_SIZE' when one uses the
  compressed protocol. (A compressed packet can't be more than 16M
  uncompressed)
- In net_realloc() set net->error if packet is longer than
  net->max_packet_size and change the NET structure so that next
  packet will be read into net->buff+NET_HEADER_SIZE, overwriting
  the any data that is not in the header.
- In my_net_read() (when handling compressed packets) should be changed
  so that when we got an error from net_realloc() we should ignore
  any not header data from the packet.
  (We need to store the header to be able to find the length of the packet
  we should ignore)
- When returning from my_net_read() we should return packet_error if we
  got a too long packet.
- It's ok for my_net_read() to set net->error to 0 when reading compressed
  data and use this to detect if we got a too big packet.