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).
On the first comment, OK, I push the change: didn't notice the read call.

On the second point: starting with V4, but I understand that AutoRead might be off and directly controled by the user, despite this traffic handler, right?

I see 2 scenarios:
1) If someone wants to control itself the AutoRead feature, then I see no reason why readLimit shall be different than 0 since this handler will not be able to control the bandwidth then...  Therefore no limitation will be done, and the user is able to do what he/she wants.

I understand this not enough.

2) Ok let say that someone wants however to control when it comes on, and then let the traffic handler control only when it is on.
The issue is:
a) as long at it is ON: the handler will make it OFF and ON as desired
b) the issue is when the user decide to make it OFF:
- If there is no ReopenReadTimerTask on going, no issue
- If there is one, the task will reopened the AutoRead, despite the desire of the user.

We might then propose something that do the following:

If someone wants to use setAutoRead(false) manually, despite the traffic handler, add a specific method to allow the user to say to the handler to not reopened the read ops.
But it could be buggy (if someone forget that such a handler is in the pipeline and therefore not calling this specific method).

WDYT?