experimental introduction of a bounded queue and rejection handler

[jsvd]

Currently the beats input will accept connections and pass the work of decoding the message to an executor that has an unbouded queue.

This makes it so that the number of batches in flight in Logstash's off heap memory will equal the number of beats (more if pipelining is enabled).

To avoid this, this draft PR introduced a bounded queue for the executor where, after the queue is full, the netty group executor's threads will continuously try to submit the message for processing until there is room in the queue.

[jsvd]

This PR doesn't really help a thundering herd of beats that fills in the direct memory with not-yet-complete Batches.

Closing this in favor of #410, that monitors direct memory usage every time a 64k chunk is read in a socket channel, providing tighter control of memory usage.