Adding context to Http2FrameObserver

Motivation:

The Http2FrameObserver isn't provided the ChannelHandlerContext when
it's called back. This will force observers to find an alternative means
of obtaining the context if they need to do things like copying buffers.

Modifications:

Changed the Http2FrameReader and Http2FrameObserver to include the
context. Updated all other uses of these interfaces.

Result:

Frame observers will now have the channel context.
Fix a race in Http2ConnectionRoundtripTest that could lead to a NPE.
Fix build for Http2ConnectionRoundtripTest
Various fixes for compliance with HTTP/2 spec

Motivation:

A few items were identified where the http2 codec is out of compliance
with the spec.

Modifications:

- Fixed handling of priority weight on the wire. Now adding 1 after
reading from the wire and subtracing 1 before writing.

- Fixed handling of next stream ID. Client streamIds were starting at 3,
but they need to start at 1 to allow the upgrade from HTTP/1.1. Also
making next stream ID logic more flexible. Allowing the next created
stream to be any number in the sequence following the previously created
stream.

- Disallowing SETTINGS frames with ENABLE_PUSH specified for server
endpoints. This means that attempts to write this frame from a server,
or read it from a client will fail.

Result:

The http2 implementation will be more inline with the spec.
Apply HTTP/2 local settings after ACK is received

Motivation:

Previously local settings is applied on its transmission.  But this
makes settings value out-of-sync with remote endpoint.  The
application of local settings must be done after the remote endpoint
sends back its SETTINGS ACK.  This synchronization is vital to the
protocol.  Suppose that server sends SETTINGS_HEADER_TABLE_SIZE 0 on
connection establishment and resizes its header table size down to 0.
Meanwhile, client sends HEADERS which has header block encoded in
default 4096 header table size, because client has not seen the
SETTINGS from server.  Server tries to decode received HEADERS but due
to the difference of header table size, decoding process may fail.

Modifications:

We don't apply settings on transmission.  Instead, we keep track of
outstanding settings in FIFO queue.  When we get ACK, we pop oldest
outstanding settings and apply its values.

Result:

The outstanding settings values are applied when its ACK is received,
which is compliant behavior to the HTTP/2 specification.
[#2485] Use RecvByteBufAllocator for all allocations related to read from Channel

Motivation:
At the moment we sometimes use only RecvByteBufAllocator.guess() to guess the next size and the use the ByteBufAllocator.* directly to allocate the buffer. We should always use RecvByteBufAllocator.allocate(...) all the time as this makes the behavior easier to adjust.

Modifications:
Change the read() implementations to make use of RecvByteBufAllocator.

Result:
Behavior is more consistent.
Use ByteBuf.readSlice(...).retain() to minimize memory copies.

Motivation:
At the moment we call ByteBuf.readBytes(...) in these handlers but with optimizations done as part of 25e0d9d we can just use readSlice(...).retain() and eliminate the memory copy.

Modifications:
Replace ByteBuf.readBytes(...) usage with readSlice(...).retain().

Result:
Less memory copies.
Merging HTTP/2 preface logic into connection handler

Motivation:

The HTTP/2 connection preface logic is currently handled in two places.
Reading/writing the client preface string is handled by
Http2PrefaceHandler while the reading/writing of the initial settings
frame is handled by AbstractHttp2ConnectionHandler. Given that their
isn't much code in Http2PrefaceHandler, it makes sense to just merge it
into the preface handling logic of AbstractHttp2ConnectionHandler. This
will also make configuring the pipeline simpler for HTTP/2.

Modifications:

Removed Http2PrefaceHandler and added it's logic to
AbstractHttp2ConnectionHandler. Updated other classes depending on
Http2PrefaceHandler.

Result:

All of the HTTP/2 connection preface processing logic is now in one
place.
More robust native library discovery in Mac OS X

Motivation:

Some JDK versions of Mac OS X generates a JNI dynamic library with '.jnilib' extension rather than with '.dynlib' extension.  However, System.mapLibraryName() always returns 'lib<name>.dynlib'. As a result, NativeLibraryLoader fails to load the native library whose extension is .jnilib.

Modification:

Try to find both '.jnilib' and '.dynlib' resources on OS X.

Result:

Dynamic libraries are loaded correctly in Mac OS X, and thus we can continue the OpenSslEngine work.
Minimize memory footprint of HashedWheelTimer and context-switching

Motivation:
At the moment there are two issues with HashedWheelTimer:
* the memory footprint of it is pretty heavy (250kb fon an empty instance)
* the way how added Timeouts are handled is inefficient in terms of how locks etc are used and so a lot of context-switching / condition can happen.

Modification:
Rewrite HashedWheelTimer to use an optimized bucket implementation to store the submitted Timeouts and a MPSC queue to handover the timeouts.  So volatile writes are reduced to a minimum and also the memory foot-print of the buckets itself is reduced a lot as the bucket uses a double-linked-list. Beside this we use Atomic*FieldUpdater where-ever possible to improve the memory foot-print and performance.

Result:
Lower memory-footprint and better performance
Not throw a Http2Exception when a ChannelFuture is returned

Motivation:
At the moment we have some methods that return a ChannelFuture but still throw a Http2Exception too. This is confusing in terms of semantic. A method which returns a ChannelFuture should not throw an Http2Exception but just fail the ChannelFuture.

Modifications:
* Make sure we fail the returned ChannelFuture in cases of Http2Exception and remove the throws Http2Exception from the method signature.
* Also some cleanup

Result:
Make the API usage more clear.
Fix the life cycle mapping problem with m2e

Motivation:

It should be frictionless to import our project into Eclipse

Modifications:

Exclude the plugins with missing life cycle mapping. They are not useful
for use with IDE anyway.

Result:

Fixes #2488
Netty is imported into Eclipse without a problem.
Fix buffer leaks in HTTP2
Fix capacity check bug affecting offheap buffers
Correctly release buffer when testing DelegatingHttp2ConnectionHandler
Better implementation of AttributeMap and also add hasAttr(...). See [#2439]

Motivation:
The old DefaultAttributeMap impl did more synchronization then needed and also did not expose a efficient way to check if an attribute exists with a specific key.

Modifications:
* Rewrite DefaultAttributeMap to not use IdentityHashMap and synchronization on the map directly. The new impl uses a combination of AtomicReferenceArray and synchronization per chain (linked-list). Also access the first Attribute per bucket can be done without any synchronization at all and just uses atomic operations. This should fit for most use-cases pretty weel.
* Add hasAttr(...) implementation

Result:
It's now possible to check for the existence of a attribute without create one. Synchronization is per linked-list and the first entry can even be added via atomic operation.