Upgrade os-maven-plugin to fix an issue with IntelliJ IDEA on Windows
Work around the system configuration issue that causes NioSocketChannelTest to fail

Motivation:

On some ill-configured systems, InetAddress.getLocalHost() fails.  NioSocketChannelTest calls java.net.Socket.connect() and it internally invoked InetAddress.getLocalHost(), which causes the test failures in NioSocketChannelTes on such an ill-configured system.

Modifications:

Use NetUtil.LOCALHOST explicitly.

Result:

NioSocketChannelTest should not fail anymore.
Upgrade to netty-tcnative 1.1.30.Fork2 to support Windows
More realistic ByteBuf allocation benchmark

Motivation:

Allocating a single buffer and releasing it repetitively for a benchmark will not involve the realistic execution path of the allocators.

Modifications:

Keep the last 8192 allocations and release them randomly.

Result:

We are now getting the result close to what we got with caliper.
Optimize PooledByteBufAllocator

Motivation:

We still have a room for improvement in PoolChunk.allocateRun() and
Subpage.allocate().

Modifications:

- Unroll the recursion in PoolChunk.allocateRun()
- Subpage.allocate() makes use of the 'nextAvail' value set by previous
  free().

Result:

- PoolChunk.allocateRun() optimization yields 10%+ improvements in
  allocation throughput for non-subpage allocations.
- Subpage.allocate() optimization makes the subpage allocations for
  tiny buffers as fast as non-tiny buffers even when the pageSize is
  huge (e.g. 1048576) because it doesn't need to perform a linear search
  in most cases.
Do not use a pseudo random for tree traversal

Motivation:

If we make allocateRun/SubpageSimple() always try the left node first and make allocateRun/Subpage() always tries the right node first,  it is more likely that allocateRun/Subpage() will find a node with ST_UNUSED sooner.

Modifications:

- Make allocateRunSimple() and allocateSubpageSimple() always try the left node first.
- Make allocateRun() and allocateSubpage() always try the right node first.
- Remove randome

Result:

We get the same performance without using random numbers.
Correction on StringBuilder default init size

Motivation:
The default StringBuilder size is too small (data.length + 4) while it will be 2*data.length (byte to Hex) + 5 "-" char (since 5 peaces appended).

Modification:
Changing initial size to the correct one

Result:
Allocation of the correct final size from the beginning for this StringBuilder.
codec-http: Document the semantics of HttpResponseStatus equality and comparison
[#2523] Fix infinite-loop when remove attribute and create the same attribute again

Motivation:
The current DefaultAttributeMap cause an infinite-loop when the user removes an attribute and create the same attribute again. This regression was introduced by c3bd7a8ff10021026b0c223d36f022dbbf4fe397.

Modification:
Correctly break out loop

Result:
No infinite-loop anymore.
Fix broken CompositeMatcher

Motivation:

ChannelMatchers#CompositeMatcher inverts matches result.

Modifications:

Switched return values.

Result:

ChannelMatchers#CompositeMatcher will return correct results.
[#2525] Use VoidChannelPromise in MessageToMessageEncoder when possible

Motivation:
At the moment MessageToMessageEncoder uses ctx.write(msg) when have more then one message was produced. This may produce more GC pressure then necessary as when the original ChannelPromise is a VoidChannelPromise we can safely also use one when write messages.

Modifications:
Use VoidChannelPromise when the original ChannelPromise was of this type

Result:
Less object creation and GC pressure
Pluggable algorithm to choose next EventLoop

Motivation:

Currently when a new event loop is needed to register a channel our EventLoopGroup implementations just
use a round-robin like algorithm to choose the next event loop. Unfortunately this is not always good
enough as different event loops may become more busy than others over time. This is especially true when
an application handles different kinds of connections (long-living and short-living). This change allows
developers to plug in their own algorithms to choose the next event loop and to collect metrics about the
busyness of the event loops. See #1230

Modifications:

- TODO

Result:

- Developers can plug in their own algorithms into MultithreadEventLoopGroup constructors.
- Developers can gather metrics/feedback from the event loops and use the data in their custom algorithms.