Peter M. Groen / FlashMQ

Cross-protocol, received messages on existing subscriptions would get
retain=1, which is wrong.

Was caught by refactor testNotMessingUpQosLevels away from QMQTT, which
didn't trip on this bug.

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.

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.

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 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.

The only thing it did was false trip the fuzzer.

Diff with 'ignore whitespace' looks clean.

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

The CONACK indicated that it's not supported, and the specs say to issue
a disconnect when they're used after all.

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

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

It erroneously referred to the system function 'dup' now...

Also fix some bugs:

- The password can be binary data.
- The will topic is now also checked.

This allows easier saving of MQTT5 properties, for which a new file
version for retained messages is created. It uses the packet parsing logic.

It went over boundry when there were no properties.

Also changed will logic in disconnect: only clear it when it's a
successful disconnect.

- 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.