Peter M. Groen / FlashMQ

This causes confusion when saving sessions, because copy objects are
being destroyed.

When you have the server generate a client ID: "It MUST then process the
CONNECT packet as if the Client had provided that unique ClientID, and
MUST return the Assigned Client Identifier in the CONNACK packet".

So, this means allowing an empty client ID, even for non-clean start,
should be allowed.

This went wrong when the char was negative.

When the plugin was enabled, it would never got past the fail of not
having a password file entry. This is fixed.

The reauth didn't work because setting the return data took the path of
first auth, hitting a protection exception. This is fixed.

Writing extended auth tests involved some refactoring, to create a
separate method to parse the auth packet data, because I needed it in
the test too.

Also properly fsynced it, and the dir it's in.

Also fix sending an UNSUBACK instead of SUBACK on unsubscribe.

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

And make it test accross protocol versions.

And also made it test accross protocol versions.

And make it test cross-protocol.

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

The extraneous creation would happen when multiple subscribes at
different QoS levels happen.

Also add a test to test all scenarios.

This also fixes session clean_start, which was never done since the
MQTT5 refactor to clean_start (vs clean session).

It timed out sometimes. When it works, it doesn't even take longer,
because it's just the timeout.

It was caught by an assert. In release mode, this simply meant
subscribing to 0 still gave you QoS messages.

This was old debug code.

The effect is that QoS now doesn't do unnecessary queueing.

Fixes assertion error in debug only.

It was flakey. I also ported it to the new test client.

They now contain sender info of publishes.

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.