Better fix for TrafficShapingHandlerTest

Motivation:
The test procedure is unstable when testing quick time (factor less or equal to 1). Changing to default 10ms in this case will force time to be correct and time to be checked only when factor is >= 2.

Modifications:
When factor is <= 1, minimalWaitBetween is 10ms

Result:
Hoping this version is finally stable.
Fix for issue #2765 relative to unstable test

Fix for issue #2765 relative to unstable trafficshaping test procedure

Motivation:
The test procedure is unstable due to not enough precise timestamping during the check.

Modifications:
Reducing the test cases and cibling "stable" test ("timestamp-able") bring more stability to the tests.

Result:
Tests for TrafficShapingHandler seem more stable (whatever using JVM 6, 7 or 8).
Same version as in 4.0, 4.1 and Master.
Correct name

Motivation:
Wrong name!

Modification:
Change name

Result:
Compile ok
Update TrafficShapingTest.java
Fix for issue #2765 relative to unstable trafficshaping test procedure

Motivation:
The test procedure is unstable due to not enough precise timestamping
during the check.

Modifications:
Reducing the test cases and cibling "stable" test ("timestamp-able")
bring more stability to the tests.

Result:
Tests for TrafficShapingHandler seem more stable (whatever using JVM 6,
7 or 8).

Renaming to:
	src/test/java/org/jboss/netty/handler/traffic/TrafficShapingHandlerTest.java
Minimal fix on waiting time in TrafficShaping test

Motivation:
Possibly due to very small time (< 100ms), the trafficShaping time might be a bit high in rare condition.

Modification:
Remove extra time (only stepms is kept, not minimalms).

Result:
Time shall be ok now.
Add io.netty.noJdkZlibEncoder system property

Related issue: #2821

Motivation:

There's no way for a user to change the default ZlibEncoder
implementation.

Modifications:

Add a new system property 'io.netty.noJdkZlibEncoder'.
Use JZlib-based encoder if windowBits or memoryLevel is different from
the JDK default.

Result:

A user can tell HttpContentCompressor not to use JDK ZlibEncoder even if
the current Java version is 7+.
Fix a bug in CIDR.contains(InetAddress) implementations

Related issue: #2767

Motivation:

CIDR.contains(InetAddress) implementations should always return true
when the CIDR's prefix length is 0.

Modifications:

- Make CIDR.contains(InetAddress) return true if the current cidrMask is
  0
- Add tests

Result:

Fixed the issue #2767
[maven-release-plugin] prepare release netty-3.9.4.Final
[maven-release-plugin] prepare for next development iteration
[#2426] Not cause busy loop when interrupt Thread of AbstractNioSelector

Motivation:
Because Thread.currentThread().interrupt() will unblock Selector.select() we need to take special care when check if we need to rebuild the Selector. If the unblock was caused by the interrupt() we will clear it and move on as this is most likely a bug in a custom ChannelHandler or a library the user makes use of.

Modification:
Clear the interrupt state of the Thread if the Selector was unblock because of an interrupt and the returned keys was 0.

Result:
No more busy loop caused by Thread.currentThread().interrupt()
Fix overriden methos not called

Motivation:
channelConnected was override but super was never called, while it
should. It prevents next handlers to be informed of the connection.
Also add one missing information in the toString method.

Modifications:
Add the super corresponding call, and add checkInterval  to the
toString() method

Result;
Now, if the channelConnected method is correctly passed to the the next
handler.
Change the operator order of TrafficCounter to calculate the throughput to get the correct result

Motivation:
Currently the last read/write throughput is calculated by first division,this will be 0 if the last read/write bytes < interval,change the order will get the correct result

Modifications:
Change the operator order from first do division to multiplication

Result:
Get the correct result instead of 0 when bytes are smaller than interval
[#2931] Only cancel SelectionKey if connection is not pending

Motivation:

We must only cancel the SelectionKey if the connection is not pending while try to workaround the epoll bug, otherwise we may fail to notify the future later.

Modifications:

Check if the connection is pending before cancel the SelectionKey.

Result:

Only cancel correct SelectionKeys and so also make sure the futures are notified.