Prior to this commit any acks to a PUBLISH could fail and have their failure swallowed (hidden). I’m now thinking that it is best to propagate this particular type of failure so that the calling code is able to act on it To illustrate:

1. Publisher publishes PUBLISH with QoS 1
2. Consumer receives the PUBLISH
3. Machine is really slow
4. Consumer throws a ConsumeFailed given that 30 seconds (the local ack timeout) has passed and it hasn't received a local PUBACK
5. A PUBACK is then provided locally

Step 5 will result in there being no route to the Consumer as it previously stopped at step 4. The exception reflecting the inability to route was swallowed up.

It feels like an error to publish an ACK for something more than once, hence the change to propagate the error.

We increase the timeout default for slow acks given super slow machines

This commit restores the behaviour to that of prior to this PR, but adds in the ability for the client API to receive a notification on the acks having completed - successfully or not. This new behaviour utilises the existing completion notification mechanism for server SubAcks.

That's all of the acks now, for consistency.