Peter M. Groen / FlashMQ

This includes some logic to have threads finish their work before
quitting.

- Delay is properly counted from moment of disconnect.
- When a session is picked up again, the will is not sent.
- An actual fix to what I tried a few commits ago: fix sending will
  twice.

This logic should make storing wills also easier.

I think it's very hard to distinguish between protocol error and
malformed packet. It's kind of arbitrary...

Because clients can now also exist as dummy objects, I had to add some
extra checks.

Also split up handlePublish() and the new parsePublishData().

I think it's correct, but mosquitto_sub doesn't seem to support it, so I
can't test.

Also some other stuff I happen to see.

This replaces the old style checking of expired sessions once every 10
minutes or so.

which also has implications on how I think to handle 'queuePacketAtSub'

The behavior for MQTT3 clients in the same, but I replaced the term
'clean session' and described the behavior in MQTT5 terms, of 'clean
start' and an expiry interval.

Most of it is limits we already implemented non-standard compliant.

This is a preparation for MQTT5, because when there are receivers and
publishers with different protocols, you can't always just write out the
same packet. You can sometimes though, so that's what the copy factory
determines.

This entails making copies of the original packet when necessary,
because QoS 0 doesn't have a packet id. I tried to keep it to an
absolute minimum and do some precarious optmizations for it. There are
tests though.

It caused really funky behavior. When a destructed client closed fd 0,
eventfd() would give 0 back as fd. This would then later give errors.

This makes more sense, logically, and also helps in tests I'm about to
write.

One fix is client destruction happening on the correct thread (when
kicking another one off with existing client ID). This caused deadlocks
on the subscriptions lock during a race condition when
doKeepAliveCheck() also ran.

A related deadlock was that the queued functions were executed while
holding the lock taskQueueMutex. Together with the subscriptions lock,
that was executed in the $SYS topic function, this also caused
deadlocks.

One part is a fix, where the frame was advertised to be bigger than it
was.

The other change is making it possible to send chunks larger than the
initial buffer size, by resizing the buffer (and resetting it later).

Mandatory normative statement MQTT-3.1.2-6.

Also fixes not downgrading QoS on subscribe.

My IDE didn't understand them for finding symbols, apparently.

Having threads creates instability for the fuzzer, and we don't need
them.