Without this change an attacker would be able to stop the emcute server
by sending a crafted packet triggering this branch. The solution is
using `continue` instead of `return`.
The length field in an MQTT packet carries the _total_ length of the
packet. If it is below 256 (i.e. fits in one byte) only one byte is
used for the length field. If it is larger than that 3 bytes are used,
with the first byte having the value `0x01` and the remaining bytes
representing the length in as a 2 byte unsigned integer in network byte
order. Resulting from that it can be assessed that the check in
`emcutes`'s `set_len()` function is wrong as it needs to be checked if
`len` is lesser or equal to `0xff - 1`. `len <= (0xff - 1)` can be
simplified to `len < 0xff`. For some larger packages this safes 2 bytes
of wasted packet space.
`len` is used with the `memcpy()` to copy the payload to `tbuf`. With a
payload provided that is just long enough to fill `tbuf`, `len += 6`
leads to the `memcpy()` overriding data after `tbuf` (e.g. the
`mutex` that is unlocked right after) and thus resulting in potential
segmentation faults.
Additionally `+ 6` can only be applied if the total packet length is
below 256 (see spec), so `len + pos` is what needs to be provided to the
corresponding send functions instead (`pos` adapts to the header length
of the PUBLISH message).