Peter M. Groen / FlashMQ

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.

They don't need object state.

The code allowed one to try to upgrade a read lock to a write lock,
which would/could fail.

In the existing code, the only attempted double lock was a write lock,
so this change doesn't actually fix anything, but it's clearer, and we
can make do with the lock that was removed. It just takes a bit more
overhead on app start-up, to place a lock per message.

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.

There's no point in keeping a vector per nanosecond.

There's no point in keeping a vector of removals per nanosecond.

This is fast(er).

This is way faster.

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.

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.

I didn't count the seconds it was already waiting. It does now.

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

This is better in line with how the copy factory is meant to be used. It
actually broke on the assert on 'externallyReceived' before.

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

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

I think it's very hard to distinguish between protocol error and
malformed packet. It's kind of arbitrary...

Also fixes a bug in new interval calculation.

But, this is a safe point before I will refactor it. I will remove the
appStartTime and session last touched. With the new queued removals,
this is no longer necessary.

This replaces the old style checking of expired sessions once every 10
minutes or so.

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 saves some allocations.

This also meant having to set the C++ standard to 2014.

The getCopy() methods of sessions and mqttpackets can't be changed,
because of access errors (private).

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.

Functionally, this doesn't change anything.