Improve fix for #2900 and adding prevention of OOM

Motivation:
When a huge amount of data are written, the current behavior of the
TrafficShaping handler is to limit the delay to 15s, whatever the time
the previous write occurs. This is wrong, and when a huge amount of
writes are done in a short time, the traffic is not correctly shapened.

Also the "bandwidth" compute on write is only on "acquired" write
orders, not on "real" write orders.

Finally, there is a high risk of OOM if one is not using for instance
<code>ChannelFuture.addListener()</code> to handle the write buffer
bufferisation in the TrafficShapingHandler.

Modifications:
The current write delay computation takes into account the previous
write delay and time to check is the 15s delay (maxTime) is exceeded
really or not.
Also the algorithm is review and seems more stable and accurate.

When the real write occurs, the statistics are update accordingly on a
new attribute.

Various examples are shown in one added example (example.traffic),
and in particular a user triggered event is created to handler
writability
end of suspension.

Result;
The traffic shaping is more stable, even with a huge number of writes in
short time.
The statistics are more valuable (asked write vs real write).
Following some examples show how to prevent OOM on business handler
side.