Through the additional of a secondary signalling channel,
whenever there are sufficient messages in the queue to fill a "batch",
the processing goroutine will be immediately woken. Because the
buffered channel has double that capacity, requests should never be
delayed unless the server is actually overloaded.
This preserves the improvements of the previous commit, meaning that,
even when a batch size of 10 and a batch delay of 1s is used:
- there is no background load; if no messages are received, the server
is dormant;
- if no message was received in the last second, a new message will be
immediately processed;
- if a small number of messages are received after the first, the
additional messages will be collected and processed in a single
transaction after the configured delay;
- if enough new messages arrive to fill a batch (ie 10 in this example),
they will be immediately processed, freeing up capacity for more
messages;
- if up to double the configured number of messages arrive in a burst,
there will be sufficient capacity to cache them immediately,
regardless of how slowly the mysql server commits each transaction