Implement graceful handling for improperly formed compressed message sets

This affects validation of compressed message sets. It is possible for a buggy client to send both a null compressed message set (i.e. a wrapper message with a null value), and an empty compressed message set (i.e. a wrapper message with valid compressed data in the value field, but no actual records). In both cases, this causes an unexpected exception raised from the deep iteration, which is returned to the client as an UNKNOWN_ERROR. It would be better to return a CORRUPT_MESSAGE error.

Note also that the behavior of the empty case was potentially more problematic in versions prior to 0.10.2.0. Although we properly handled the null case, the broker would accept the empty message set and write it to the log. The impact of this appears to be minor, but may cause unexpected behavior in cases where we assume compressed message sets would contain some records.