Peter M. Groen / FlashMQ

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.

When clients connect, they get the retained messages. There is no need
to do that while holding the subscriptions lock.

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.

The initial concept of iterating over a vector being fast didn't help,
and made having many subscribers to one topic very slow.

Mandatory normative statement MQTT-3.1.2-6.

When there are many sessions, the copying action can actually take some
time, and memory. A vector is faster and uses (a little) less memory.

This is a theoretical fix, without benchmarks to support it.

Empty leaves weren't removed, causing increase in memory use.