Fix build errors due to missing dependency
Generate non-test JAR for netty-testsuite

Motivation:

So far, we generated and deployed test JARs to Maven repositories. The
deployed JAR had the classifier 'test-jar'.  The test JAR is consumed by
transport-native-epoll as a test dependency.

The problem is, when netty-transport-native-epoll pulls the test JAR as
a dependency, that Maven resolves its transitive dependencies at
'compile' and 'runtime' scope only, which is incorrect.

I was bitten by this problem recently while trying to add a new
dependency to netty-testsuite.  Because I added a new dependency at the
'test' scope, the new dependency was not pulled transitively by
transport-native-epoll and caused an unexpected build failure.

- d6160208c37cfd21b690f1a0df67776bf986b28e
- bf77bb4c3ae04778e65b8a38c2a9ec0e15207de8

Modifications:

- Move all classes in netty-testsuite from src/test to src/main
- Update the 'compile' scope dependencies of netty-testsuite
- Override the test directory configuration properties of the surefire
  plugin
- Do not generate the test JAR anymore
- Update the dependency of netty-transport-native-epoll

Result:

It is less error-prone to add a new dependency to netty-testsuite.
ensure getRawQuery is not null before appending

Motivation:

without this check then given a URI with path /path the resulting URL will be /path?null=

Modifications:

check that getRawQuery doesn't return null and only append if not

Result:

urls of the form /path will not have a null?= appended
Motivation: Sonar points out an equals comparison, where the types compared are different and don't share any common parent http://clinker.netty.io/sonar/drilldown/issues/io.netty:netty-parent:master?severity=CRITICAL#

Modifications:
Converted AsciiString into a String by calling toString() method before comparing with equals(). Also added a unit-test to show that it works.

Result:
Major violation is gone. Code is correct.
Compress the heap dump after tests are finished

Motivation:

Tests sometimes time out because it took too long to compress the
generated heap dump.

Modifications:

- Move the compression logic to a new method 'compressHeapDumps()'
- Call TestUtils.compressHeapDumps() at the end of the tests, so that
  the tests do not fail because of timeout

Result:

JUnit reports the real cause of the test failure instead of timeout
exception.
Log detailed information about renegotiation and traffic

Motivation:

We need more information to understand why SocketSslEchoTest fails
sporadically in the CI machine.

Modifications:

- Refactor SocketSslEchoTest so that it is easier to retrieve the
  information about renegotiation and the current progress

Result:

We will get more information when the test fails.
Fix checkstyle
Java ALPN provider version update

Motivation:

There was a bug in the Java ALPN library we are using.  A new version was released to fix this bug and we should update our pom.xml to use the new version.

Modifications:

Update pom.xml to use new ALPN library.

Result:

Newer versions of JDK (1.7_u71, 1.7_u72, 1.8_u25) have the bug fixed.
Do not use SLF4J/Logback API directly

Motivation:

TrafficShapingHandlerTest uses Logback API directly, which is
discouraged.  Also, it overrides the global default log level, which
silences the DEBUG messages from other tests.

Modifications:

Remove the direct use of Logback API

Result:

The tests executed after TrafficShapingHandlerTest logs their DEBUG
messages correctly.
Fix memory leak in OpenSslEngine

Motivation:

When a remote peer did open a connection and only do the handshake without sending any data and then directly close the connection we did not call shutdown() in the OpenSslEngine. This leads to a native memory leak. Beside this it also was not fireed when a OpenSslEngine was created but never used.

Modifications:

- Make sure shutdown() is called in all cases when closeInbound() is called
- Call shutdown() also in the finalize() method to ensure we release native memory when the OpenSslEngine is GC'ed

Result:

No more memory leak when using OpenSslEngine
Always return SliceByteBuf on slice(...) to eliminate possible leak

Motivation:

When calling slice(...) on a ByteBuf the returned ByteBuf should be the slice of a ByteBuf and shares it's reference count. This is important as it is perfect legal to use buf.slice(...).release() and have both, the slice and the original ByteBuf released. At the moment this is only the case if the requested slice size is > 0. This makes the behavior inconsistent and so may lead to a memory leak.

Modifications:

- Never return Unpooled.EMPTY_BUFFER when calling slice(...).
- Adding test case for buffer.slice(...).release() and buffer.duplicate(...).release()

Result:

Consistent behaviour and so no more leaks possible.
CompositeByteBuf.nioBuffers(...) must not return an empty ByteBuffer array

Motivation:

CompositeByteBuf.nioBuffers(...) returns an empty ByteBuffer array if the specified length is 0. This is not consistent with other ByteBuf implementations which return an ByteBuffer array of size 1 with an empty ByteBuffer included.

Modifications:

Make CompositeByteBuf.nioBuffers(...) consistent with other ByteBuf implementations.

Result:

Consistent and correct behaviour of nioBufffers(...)
Efficiently handle writing ( wrap(...) ) of CompositeByteBuf when using SslHandler

Motivation:

SslHandler.wrap(...) does a poor job when handling CompositeByteBuf as it always call ByteBuf.nioBuffer() which will do a memory copy when a CompositeByteBuf is used that is backed by multiple ByteBuf.

Modifications:

- Use SslEngine.wrap(ByteBuffer[]...) to allow wrap CompositeByteBuf in an efficient manner
- Reduce object allocation in unwrapNonAppData(...)

Result:

Performance improvement when a CompositeByteBuf is written and the SslHandler is in the ChannelPipeline.
Remove thepiratebay.se from the test domain list

.. due to its instability
Add OpenSslClientContext to allow creating SslEngine for client side

Motivation:

We only support openssl for server side at the moment but it would be also useful for client side.

Modification:

* Upgrade to new netty-tcnative snapshot to support client side openssl support
* Add OpenSslClientContext which can be used to create SslEngine for client side usage
* Factor out common logic between OpenSslClientContext and OpenSslServerContent into new abstract base class called OpenSslContext
* Correctly detect handshake failures as soon as possible
* Guard against segfault caused by multiple calls to destroyPools(). This can happen if OpenSslContext throws an exception in the constructor and the finalize() method is called later during GC

Result:

openssl can be used for client and servers now.
More complete OpenSslEngine SSLSession implementation

Motivation:

The current SSLSession implementation used by OpenSslEngine does not support various operations and so may not be a good replacement by the SSLEngine provided by the JDK implementation.

Modifications:

- Add SSLSession.getCreationTime()
- Add SSLSession.getLastAccessedTime()
- Add SSLSession.putValue(...), getValue(...), removeValue(...), getValueNames()
- Add correct SSLSession.getProtocol()
- Ensure OpenSSLEngine.getSession() is thread-safe
- Use optimized AtomicIntegerFieldUpdater when possible

Result:

More complete OpenSslEngine SSLSession implementation
Allow to enable client authentication on the OpenSslEngine

Motivation:

At the moment there is no way to enable client authentication when using OpenSslEngine. This limits the uses of OpenSslEngine.

Modifications:

Add support for different authentication modes.

Result:

OpenSslEngine can now also be used when client authenticiation is needed.
Use TrustManager for certificate verification

Motivation:

To make OpenSsl*Context a drop in replacement for JdkSsl*Context we need to use TrustManager.

Modifications:

Correctly hook in the TrustManager

Result:

Better compatibility
Allow to use custom TrustManagerFactory for JdkSslServerContent and OpenSslServerContext

Motivation:

When using client auth it is sometimes needed to use a custom TrustManagerFactory.

Modifications:

Allow to pass in TrustManagerFactory

Result:

It's now possible to use custom TrustManagerFactories for JdkSslServerContext and OpenSslServerContext
Use OpenSslClientContext as default if openssl is avaible

Motivation:

As we now support OpenSslEngine for client side, we should use it when avaible.

Modifications:

Use SslProvider.OPENSSL when openssl can be found

Result:

OpenSslEngine is used whenever possible