Improvement and Fix for Traffic Shapping V4.0

Motivation:
Currently Traffic Shaping is using 1 timer only and could lead to
"partial" wrong bandwidth computation when "short" time occurs between
adding used bytes and when the TrafficCounter updates itself and finally
when the traffic is computed.
Indeed, the TrafficCounter is updated every x delay and it is at the
same time saved into "lastXxxxBytes" and set to 0. Therefore, when one
request the counter, it first updates the TrafficCounter with the added
used bytes. If this value is set just before the TrafficCounter is
updated, then the bandwidth computation will use the TrafficCounter with
a "0" value (this value being reset once the delay occurs). Therefore,
the traffic shaping computation is wrong in rare cases.

Secondly the traffic shapping should avoid if possible the "Timeout"
effect by not stopping reading or writing more than a maxTime, this
maxTime being less than the TimeOut limit.

Thirdly the traffic shapping in read had an issue since the readOp was
not set but should, turning in no read blocking from socket point of
view. (see #2696)

Modifications:
The TrafficCounter has 2 new methods that compute the time to wait
according to read or write) using in priority the currentXxxxBytes (as
before), but could used (if current is at 0) the lastXxxxxBytes, and
therefore having more chance to take into account the real traffic.

Moreover the Handler could change the default "max time to wait", which
is by default set to half of "standard" Time Out (30s:2 = 15s).

Finally we add the setAutoRead(boolean) accordingly to the situation, as
proposed in #2696 (the original pull request is in error for unknown
reason so this merge).

Result:
The Traffic Shaping is better take into account (no 0 value when it
shouldn't) and it tries to not block traffic more than Time Out event.

Moreover the read is really stopped from socket point of view.

This version is similar to #2388 and #2450.
This version is for V4.0, and includes the #2696 pull request to ease
the merge process.
This version is also compatible with V4.1 and Master (same as #2721).
@normanmaurer Is it safe to prevent ctx.read() to be called here ?
I'm not still so familiar with V4 (even if I'm now currently working on migrating to it).
My understanding: if isAutoRead() is false, this method is not called.
Here, since the handler prevents the read, it looks like it will still prevent any read, even if isAutoRead() is true, which is correct, and in particular for Global handler.
Now my first question is: the relative read operation will be called again later on?

Second question: what about the memory pressure (if isAutoRead is true and then read messages are incoming but not passed) ? Perhaps channelRead is called whatever?

Maybe should we called setAutoRead(false) if handler is blocking there to prevent future read (and then memory pressure) ? In particular for Global handler? Not sure (in particular due to concurrency issue then: who is blocking/unblocking for sure)
Damn! Not sure there is a perfect way... Maybe the first answers to my questions could limit this issue...