Peter M. Groen / FlashMQ

This requires storing the clientid and username in the Publish object.

Only split when they're needed, instead of pre-determining whether I'll
need the subtopics.

This makes the coming refactor of authentication easier.

Also treated user properties with the same brush a bit. Downside: it now
always assigns user properties to newly constructed publish objects,
even if they are not needed (because the generated packet may only be
needed for writing to the client's output buffer). But determining the
flow of when and when not they'll be needed is impossible with the
coming authentication refactor.

It's probably not good for anything.

The order packets would (mostly) arrive, is 'retained publish', then
'sub ack'. This is now fixed.

This also stablizes test_retained_changed(). The test was also
refactored to use the new test client.

This prevents confusion when another instance of FlashMQ is running.

This is not the final way. For instance, when SSL connections will also
be tested, this won't work anymore.

A recent refactor caused this fuzz mode to crash because the thread data
wasn't set.

There was a null dereference on a call of member function
Client::sendOrQueueWill(). Null clients shouldn exist in the list and
this was the only place it could have come from. But, I never got proof.

No issues were reported, but I noticed the theoretical issue.

When SSL wants the app to retry, it stands to reason that the local
write buffer needs to be grown (read: reallocated) to hold the
application bytes. At that point, the buffer is no longer where it was
originally.

This fixes segfaults.

I've see various variations, like mqtt and mqttv31. The 3.1.1 specs are
clear what it should be, but the 3.1 specs aren't. So, allowing
anything with mqtt in it.

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.

Will be used for the test client I have in mind.

Will be used for the test client I have in mind.

This is necessary for the test client I have in mind, so I can re-use
this code in that new test client which has no MQTT behavior, but just
returns packets (meaning I have to be able to parse them without
initiating handling).

This is necessary for the test client I have in mind, so I can re-use
this code in that new test client which has no MQTT behavior, but just
returns packets (meaning I have to be able to parse them without
initiating handling).

And also to future parse... methods.

This is necessary for the upcoming new test client.

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.

Instead of the thread data, which didn't make sense.

This required adding a global stats object.

It also contains a bit of refactor to make a type out of the derived
counters.

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

They don't need object state.

It tested the wrong thing. Tests still pass.

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