Peter M. Groen / FlashMQ

Now that parsing and handling of packets is separated, we can use the
main code to parse packets in the new FlashMQTestClient. This allows
great flexibility in inspecting the server response in a flexible
manner.

We now also have the ability to make tests for MQTT5 features.

This needed a separation: getting the current thread, and getting the
thread of the client you're queueing a command for.

This also resolves a circular reference between Client and ThreadData.

This makes much more sense than returning the amount of messages sent
all the way up the call stack.

This fixes clients being disconnected after reducing the max value and
reloading the settings.

Check events are placed in a sorted map based on the last activity and
keep-alive interval of the client.

This makes it more accurate and reduces system load because it saves
unnecessary checking.

It merely drops packets when they exceed it. The specs are unclear about
whether you're supposed to delay transmission until the quota is
non-negative again. I decided against it because of increased
complexity, and because on a continously overloaded client, this makes
no sense.

Effectively, this formalizes the 'max qos pending' mechanism that was
already in place.

It also includes PUBACK/PUBREL/PUBCOMP error handling, because that
needed to be done for proper quota control.

This also contains some fixes/unifications for traditional
authentication, error handling specifically.

This should prevent stale data from old clients from manipulating the
session.

On server shutdown and when taking over a session.

On disconnect, wills are queued first, we wait for the queueing to be done, then
initiate disconnect.

When TCP buffers are full and fds are not reported by epoll, the thread
loop still exits and clients are just closed on exit.

This required a special type WillPublish to make this easier and more
logical.

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

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.

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.

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.

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.

This can be called by a fuzzer like afl-fuzz.

This allows creation of multiple listeners, with different protocols
and/or SSL certificates.

Related change: settings is now a class that is copyable and assignable,
and is done so to each thread on reload.

Semi-related fix: fix crash in quit when multiple threads initiated it.
This came to light when testing the auth plugin settings.

The ping/pong is actually untested at this point, because Paho (my test
client for now) doesn't do those. I wonder if any do, because MQTT
already has ping/pong.

Also changed the disconnect reason a little: it now shows them all, so I
don't have to worry about which one is more important.