…consumenum workerthe consumenum worker consumes up to a certain # of messages, and onlyapplies the configured timeout to a per-message consumption, breakingout of the consume loop when:1. the end of the partition is reached (if partition eof messages areenabled)2. a consume times out3. the batch size is filledthis leaves the worker susceptible to slow-loris type issues, wheremessages come in at a cadence *just* under the timeout (e.g. every 900milliseconds) -- with a batch size of 1000, that means that`consumer.consume(1000, 1000, cb)` could take as many as 900 secondsto complete, which is less than ideal.introduce a configuration in the consumenum worker that allows callersto specify a "total" timeout that gets applied to the entire operation-- when exceeded, we break out of the loop and return the batch, nomatter how many messages were read.

…++-landthis builds on the previous commit by:1. implementing the total consume timeout parameter on the consumemethod's binding2. cleaning up the argument conversions a little bit to make themcleaner to read -- instead of deciding whether we're in thetwo-argument consume(timeout, cb) variant or the newly-4-argumentconsume(timeout, totalTimeout, num, cb) variant based on the type ofthe 2nd argument, it instead looks at the # of arguments

builds on top of the previous two commits and threads the totalconsume timeout value into javascript-land. the default is`undefined`, as that will result in no behavioral changes forconsumers. the new behavior is thus entirely opt-in.

…ants

…single message

…hecks