Peter M. Groen / FlashMQ

And one line about correlation data that was a bug.

I need to decide what to do with getPublishData

and that disabled test needs repurposing.

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.

For the coming MQTT5 support, I'll need this a lot.

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 doesn't actually fix a real bug, just makes assumptions clear.

Because that's what's it is now.

A lot of code can be refactored to get the settings from this now, but
I'm not going to do that yet.

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.

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

It caused typical global variable issues, showing in the retained
messages recursive alghorithm breaking, because the referenced subtopics
changed half way (see previous commit of the test for it).

I need to perform some benchmarks to see if I need to devise an
alternative.

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.

MQTT-3.8.3-3

MQTT-3.6.1-1

[MQTT-2.3.1-1]

I have no explanation for it, but it happens (with QMQTT, should it
matter).

There were bugs in which authentication object was used when, causing
threadings bugs. Instead of getting from the 'sender', we can just store
a thread local pointer.

Files are simple serialized bytes prefaced by lengths. File is hashed to
verify integrity. This was also a good way preventing unexpected errors
when trying to crash the parser by having it load a different file.

This change includes some refactoring that was necessary:

- It 'fixes' looking at the wrong thread's authentiction. This is still
  wrong though. It will be fixed by a thread local pointer in the next
  commit.
- Deadlocks with yourself are handled in rwlockguard.
- QoSPacketQueue is now a class.
- Probably other tweaks.

This performs a whole lot better.

Also include a few stats.