BUG/MINOR: tcpcheck: fix out-of-bounds reads on short MySQL error packets

BUG/MINOR: tcpcheck: fix out-of-bounds reads on short MySQL error packets

tcpcheck_mysql_expect_packet() only verifies that the packet header is
present before reading inside it.

This covers the 3 length bytes and the sequence id, but not the packet type
byte read at offset+4 right after. Then the whole packet is checked against
the buffer, which only guarantees that 4 bytes past offset were received.

When the packet announces a length lower than 4, the error branch below is
entered even though the bytes it reads were never received: it reads the
error code at offset+5 and offset+6 and uses offset+7 as the start of the
message body, while the body length is computed as b_data()-offset-7, which
wraps around when b_data() is lower than offset+7. A 5-byte response, i.e. a
packet announcing plen == 0 followed by a 0xff byte, is enough to trigger
this.

The wrapped length does not lead to a copy today because chunk_istcat()
refuses to append more than b_room(), but the reads still happen and the
error code and status reported are garbage.

Thus, first make sure the packet type byte is available before reading it,
and then reject error packets announcing less than 4 payload bytes, the
minimum for the packet type, a 2-byte error code and at least one byte of
description. As a consequence, such packets are now reported as a Layer7
invalid response instead of a Layer7 wrong status with a bogus error code,
and a response carrying only the 4 header bytes is now considered incomplete
and waits for more data instead of being parsed from bytes that were never
received. Truncated responses keep waiting for more data as before.

This bug is present since 2.2, so it should be backported to all
maintained branches.

Co-authored-by: QiuYitai <74493355+QiuYitai@users.noreply.github.com>