New proposal to take into account setAutoRead(boolean) setting directly
by the user in the program external to this handler.

1) setAutoRead(false) is only set when both isAutoRead and the
isHandlerActive are True

a) If isAutoRead is False => either set by the user, either by a
previous set by this handler

b) If isAutoRead is True and isHandlerActive is False means that the
handler set the AutoRead to True but the user changes it manually after

2) When the thread to reopen the channel is called, is isAutoRead and
isHandlerActive are False, it means that the user stopped manually the
channel, therefore only the status of the handler must be changed. Else
both the status and the channel are set to active.

3) Re implement read method since GlobalTrafficShappingHandler could
have the following:
Whatever isAutoRead, if the handler is not active, the ctx.read() shall
not be called until the isAutoRead is reset.



Doing this way, the user could act directly on setAutoRead, while being
correct for the handler (both in Channel and Global
TrafficShappingHandler):
A) If the user setAutoRead(True) while handler is not blocking: no side
effect, the handler can still decide to block after (due to traffic)

B) If the user setAutoRead(True) while handler is blocking: the handler
will block the next read() until the handler is not blocking again -
thread removing the status - (handler is prioritary there due to
traffic)

C) If the user setAutoRead(False) while handler is not blocking: no side
effect, the channel remains blocked until the user unblocks it

D) If the user setAutoRead(False) while handler is blocking: the channel
will remains blocked until the thread removed the status on the handler,
therefore the user's setAutoRead(false) will be ignored after that point
(only issue seen?)