Adding support for HTTP/2 initialization handshake.

Motivation:

The current HTTP/2 support does not properly comply with the HTTP/2 spec
wrt startup.

Modifications:

Changed the frame codec as well as the connection handler to support
exchange of the connection preface, followed immediately by an initial
settings frame.

Result:

The HTTP/2 initialization handshake will be in compliance with the spec.
Will need more work to support the upgrade protocols, however :)
Add a Example for Memcache Binary Codec

Motivation:
Currently, there exists no example which shows how to use the memcache binary
protocol.

Modifications:
Add an example client and client handler to show how to utilize the binary
protocol in a memcache client with a simple interactive shell.

Result:
Users looking for an example can now start off with the provided one.
[#2390] Minimize memory usage of NioDatagramChannel

Motivation:
At the moment we create a HashMap that holds the MembershipKeys for multicast with every NioDatagramChannel even when most people not need it at al

Modifications:
Lazy create the HashMap when needed.

Result:
Less memory usage and less object creation
Fix error that causes (up to) double memory usage

Motivation:

PoolArena's 'normalizeCapacity' function was micro-optimized some
time ago to remove a while loop. However, there was a change of
behavior in the function as a result. Capacities passed into it
that are already powers of 2 (and >= 512) are doubled in size. So
if I ask for a buffer with a capacity of 1024, I will get back one
that actually uses 2048 bytes (stored in maxLength).

Aligning to powers of two for book keeping ease is reasonable,
and if someone tries to expand a buffer, you might as well use some
of the previously wasted space. However, since this distinction
between 'easily expanded' and 'costly to expand' space is not
supported at all by the APIs, I cannot imagine this change to
doubling is desirable or intentional.

This is especially costly when using composite buffers. They
frequently allocate components with a capacity that is a power of
2, and they never attempt to expand components themselves. The end
result is that heavy use of pool-backed composite buffers wastes
almost half of the memory pool (the smaller / initial components are
<512 and so are not affected by the off-by-one bug).

Modifications:

Although I find it difficult to believe that such an optimization
is really helpful, I left it in and fixed the off-by-one issue by
decrementing the value at the start.

I also added a simple test to both attempt to verify that the
decrement fixes the issue without introducing any other change, and
to make it easy for a reviewer to test the existing behavior. PoolArena
does not seem to have much testing or testability support though so
the test is kind of a hack and will break for unrelated changes. I
suggest either removing it or factoring out the single non-static
portion of normalizeCapacity so that the fragile dummy PoolArena is
not required.

Result:

Pooled allocators will allocate less resources to the highly
inefficient and undocumented buffer section between length and
maxLength.

Composite buffers of non-trivial size that are backed by pooled
allocators will use about half as much memory.
SPDY: refactor frame codec implementation

Motivation:

Currently, the SPDY frame encoding and decoding code is based upon
the ChannelHandler abstraction. This requires maintaining multiple
versions for 3.x and 4.x (and possibly 5.x moving forward).

Modifications:

The SPDY frame encoding and decoding code is separated from the
ChannelHandler and SpdyFrame abstractions. Also test coverage is
improved.

Result:

SpdyFrameCodec now implements the ChannelHandler abstraction and is
responsible for creating and handling SpdyFrame objects.
Add missing override annotations
Cleaning up code for determining whether the HTTP/2 connection header
and initial settings frame were sent.

Motivation:

The current logic for marking the connection header and initial settings
frame is a bit complicated.

Modifications:

- Http2FrameEncoder, Http2ConnectionHandler: removed sent listeners and
set the sent flag immediately.

Result:

Just a code cleanup ... behavior is the same.
HTTP2 example server should also log.

Motivation:

The HTTP2 example client logs, and it's useful to show what's
going on.  It'd be sweet if the server did too.

Modifications:

Added Http2FrameLogger to example server pipeline.

Result:

HTTP2 example server will log frames.
Fix buffer leaks in SPDY test

Motivation:

Fix leaks reported during SPDY test.

Modifications:

Use ReferenceCountUtil.releaseLater(...) to make sure everything is released once the tests are done.

Result:

No more leak reports during run the tests.
Fix buffer leaks in SpdyFrameDecoderTest

Motivation:

Fix leaks reported during running SpdyFrameDecoderTest

Modifications:
Make sure the produced buffer of SpdyFrameDecoder is released

Result:

No more leak reports during run the tests.
 Fix missed buffer leaks in SpdyFrameDecoderTest

 Motivation:
 Fix leaks reported during running SpdyFrameDecoderTest

Modifications:
Make sure the produced buffers of SpdyFrameDecoder and SpdyFrameDecoderTest are released

Result:

No more leak reports during run the tests.
[#2376] Add support for SO_REUSEPORT in native transport

Motivation:
In linux kernel 3.9 a new featured named SO_REUSEPORT was introduced which allows to have multiple sockets bind to the same port and so handle the accept() of new connections with multiple threads. This can greatly improve the performance when you not to accept a lot of connections.

Modifications:
Implement SO_REUSEPORT via JNI

Result:
Be able to use the SO_REUSEPORT feature when using the EpollServerSocketChannel
[#2377] Implement epoll based DatagramChannel

Motivation:
There is currently no epoll based DatagramChannel. We should add one to make the set of provided channels complete and also to be able to offer better performance compared to the NioDatagramChannel once SO_REUSEPORT is implemented.

Modifications:
Add implementation of DatagramChannel which uses epoll. This implementation does currently not support multicast yet which will me implemented later on. As most users will not use multicast anyway I think it is fair to just add the EpollDatagramChannel without the support for now. We shipped NioDatagramChannel without support earlier too ...

Result:
Be able to use EpollDatagramChannel for max. performance on linux
[#2375] [#2404] Fix bug in respecting ChannelConfig.setAutoRead(false) and also fix Channel.read() for OIO

Motivation:
At the moment ChanneConfig.setAutoRead(false) only is guaranteer to not have an extra channelRead(...) triggered when used from within the channelRead(...) or channelReadComplete(...) method. This is not the correct behaviour as it should also work from other methods that are triggered from within the EventLoop. For example a valid use case is to have it called from within a ChannelFutureListener, which currently not work as expected.

Beside this there is another bug which is kind of related. Currently Channel.read() will not work as expected for OIO as we will stop try to read even if nothing could be read there after one read operation on the socket (when the SO_TIMEOUT kicks in).

Modifications:
Implement the logic the right way for the NIO/OIO/SCTP and native transport, specific to the transport implementation. Also correctly handle Channel.read() for OIO transport by trigger a new read if SO_TIMEOUT was catched.

Result:
It is now also possible to use ChannelConfig.setAutoRead(false) from other methods that are called from within the EventLoop and have direct effect.
[#2405] Add support for SO_REUSEPORT to EpollDatagramChannel

Motivation:
With SO_REUSEPORT it is possible to bind multiple sockets to the same port and so handle the processing of packets via multiple threads. This allows to handle DatagramPackets with more then one thread on the same port and so gives better performance.

Modifications:
Expose EpollDatagramChannelConfig.setReusePort(..) and isReusePort()

Result:
Allow to bind multiple times to the same local address and so archive better performance.
[#2144] Fix NPE in Local transport caused by a race

Motivation:
At the moment it is possible to see a NPE when the LocalSocketChannels doRegister() method is called and the LocalSocketChannels doClose() method is called before the registration was completed.

Modifications:
Make sure we delay the actual close until the registration task was executed.

Result:
No more NPE
[#2401] Improve documentation of HttpObjectAggregator

Motivation:
Make it more clear what the output of HttpObjectAggregator is and that it need to come after the encoder in the pipeline.

Modifications:
Change javadocs to make things more clear.

Result:
Better docs
Move validatePromise(...) to ChannelHandlerInvokerUtil. Related to [#2398]

Motivation:
Once a user implement a custom ChannelHandlerInvoker it is needed to validate the ChannelPromise. We should expose a utility method for this.

Modifications:
Move validatePromise(...) from DefaultChannelHandlerInvoker to ChannelHandlerInvokerUtil and make it public.

Result:
User is able to reuse code
HTTP2 example uses SSL and NPN.

Motivation:

HTTP2 is generally negotiated over SSL, makes more sense to provide an SSL example.

Modifications:

Copy the SDPY example to add SSL and NPN negotiation to the HTTP2 example.

Result:

Http2Server and Http2Client examples use SSL.
HTTP2 server should not send preface string

Motivation:

See: https://github.com/netty/netty/issues/2402
See: https://tools.ietf.org/html/draft-ietf-httpbis-http2-10#section-3.5

Only the client should send the preface string, the server should not.

"The server connection header consists of just a SETTINGS frame (Section 6.5)
 that MUST be the first frame the server sends in the HTTP/2 connection."

Modifications:

Split out Http2ClientPrefaceWriter and Http2ServerPrefaceReader from
Http2FrameEncoder and Http2FrameDecoder.  The new channel handlers are added
to the pipeline and remove themselves after the preface is written/read.

Result:

HTTP2 client sends preface, server does not, in compliance with spec.