STORM-297 Storm Performance cannot be scaled up by adding more CPU cores

STORM-297

Description and test report can be found at https://issues.apache.org/jira/browse/STORM-297
The changes consists of:
1. use netty async
2. use batch send and batch receiver messaging api
3. allow to configure multiple worker receiver threads.
4. name the executor and netty threads

@Gvain,

Unacked topology with no flow control is dangerous! 

There are two concepts, flow control and error control. You don't want acker for its performance penalty, that is no error control. But you do need flow control.

But the fact is that current storm flow control method "max.spout.pending" depends on error control channel "acker", that is the dilemma. Maybe we should seperate "max.spout.pending" from error control channel "acker" and only serves for flow control.

One work-around is that when you emit a message with SpoutOutputCollector, you emit a id with a sampling rate, for example 1%.

collector.emit(tuple, messageId), 

only 1% tuple has messageId, while 99% don't have.

In this case, you only have 1% acker traffic, reducing the performance penalty of acker, while still have some basic flow control.

Hope this helps!