Ensure the HttpResponseEncoder is always placed before the HttpObjectAggregator. Part of [#2219]
Add CONTRIBUTING.md

Motivation:
We often receive a bug report or a pull request which do not give us
enough information.  If CONTRIBUTING.md exists in the repository, Github
will display some notice in the beginning of the issue submission form,
which might increase the overall quality of the bug reports and pull
requests.

Modification:
Write CONTRIBUTING.md

Result:
Potentially higher-quality bug reports and pull requests
Update CONTRIBUTING.md
Fix buffer leak in test which was introduced while implement ZLIB_OR_NONE support. Related to [#2269]
Add content length and date headers to CORS response
[#2280] Correct logic in Native.finishConnect. Fix use of optval parameter in c getOption function. In epoll event loop, check that channel is open before processing event.
Fix buffer leak in test which was introduced while implement ZLIB_OR_NONE support. Related to [#2269]
added support for empty query parameters
[#2297] Correctly close all registered Channels on EpollEventLoop.closeAll()
ipfilter implementation for netty 4/5 [#2129]
Use bitwise operations to choose next EventExecutor if number of EventExecutors is power of two
Move the pull request guide to the developer guide

Motivation:

CONTRIBUTING.md is useful only because it lets Github show a user the
link to it so the user can check what information we need before
submitting a bug report.  However, Github does not do the same for a
pull request submission form, and thus there's no reason to keep the
information about how to submit a good pull request in CONTRIBUTING.md.

Modification:

Replace the section about issuing a pull request with the link to the
official developer guide.

Result:

CONTRIBUTING.md is easier to maintain.
Overall clean-up of ipfilter package

Motivation:

Recently merged ipfilter package has the following problems:
* AbstractIpFilterHandler could be improved to support any SocketAddress types rather than only InetSocketAddress.
* AbstractIpFilterHandler can be removed immediately after decision is made rather than keeping the outcome of the decision as an attribute.
* AbstractIpFilterHandler doesn't have a hook for the accepted addresses.
* The hook method (reject()) needs to be named in line with other handler methods (i.e. channelRejected())
* IpFilterRuleHandler should allow accepting zero rules - it's particularly useful for machine-configured setup (i.e. specifying zero rules disables ipfilter).
* IpFilterRuleType.ALLOW/DENY should be ACCEPT/REJECT for consistency.

Modifications:

* AbstractIpFilterHandler has been renamed to AbstractRemoteAddressFilter and now uses type parameter.
* Added channelAccepted() and renamed reject() to channelRejected()
* Added ChannelHandlerContext as a parameter of accept() so that accept() can add a listener to the closeFuture() of the channel. This way, UniqueIpFilter continue working even if we remove the filtering handler early.
* Various renames
  * IpFilterRuleHandler -> RuleBasedIpFilter
  * UniqueIpFilterHandler -> UniqueIpFilter

Result:

* Much cleaner API with more extensibility
Do not use finally to propagate events in AbstractRemoteAddressFilter

Motivation:

We don't really need to propagate an event when handling the event fails.

Modifications:

Do not use finally block in AbstractRemoteAddressFilter

Result:

AbstractRemoteaddressFilter does not forward an event in case of failure.
Add capacity limit to Recycler / Optimize when assertion is off

Motivation:

- As reported recently [1], Recycler's thread-local object pool has unbounded capacity which is a potential problem.
- It accesses a hash table on each push and pop for debugging purposes.  We don't really need it besides debugging Netty itself.

Modifications:

- Introduced the maxCapacity constructor parameter to Recycler.  The default default maxCapacity is retrieved from the system property whose default is 256K, which should be plenty for most cases.
- Recycler.Stack.map is now created and accessed only when assertion is enabled for Recycler.

Result:

- Recycler does not grow infinitely anymore.
- If assertion is disabled, Recycler should be much faster.

[1] https://github.com/netty/netty/issues/1841
Remove condition in ChannelHandlerAdapter.isSharable() by caching the result of the annotation lookup.

Motivation:
Remove the synchronization bottleneck and so speed up things

Modifications:
Introduce a ThreadLocal cache that holds mappings between classes of ChannelHandlerAdapater implementations and the result of checking if the @Sharable annotation is present.
This way we only will need to do the real check one time and server the other calls via the cache. A ThreadLocal and WeakHashMap combo is used to implement the cache
as this way we can minimize the conditions while still be sure we not leak class instances in containers.

Result:
Less conditions during adding ChannelHandlerAdapter to the ChannelPipeline
Fix checkstyle errors introduced by f0d1bbd63ec910b9c5bccc925bdf0b0f55db1f9c
[#2308] Use SelectorProvider.open*() to open NIO channels and so remove condition when create new NIO channels.

Motivation:
At the moment we use SocketChannel.open(), ServerSocketChannel.open() and DatagramSocketChannel.open(...) within the constructor of our
NIO channels. This introduces a bottleneck if you create a lot of connections as these calls delegate to SelectorProvider.provider() which
uses synchronized internal. This change removed the bottleneck.

Modifications:
Obtain a static instance of the SelectorProvider and use SelectorProvider.openSocketChannel(), SelectorProvider.openServerSocketChannel() and
SelectorProvider.openDatagramChannel(). This eliminates the bottleneck as SelectorProvider.provider() is not called on every channel creation.

Result:
Less conditions when create new channels.
Remove sniffer whitelist entries for NIO.2

Motivation:
Cleanup pom.xml file.

Modifications:
Remove sniffer whitelist entries for NIO.2 as we not include a NIO.2 bases transport anymore.

Result:
Less entries in pom.xml
[#2307] Remove synchronized bottleneck in SingleThreadEventExecutor.execute(...)

Motivation:
Remove the synchronization bottleneck in startThread() which is called by each execute(..) call from outside the EventLoop.

Modifications:
Replace the synchronized block with the use of AtomicInteger and compareAndSet loops.

Result:
Less conditions during SingleThreadEventExecutor.execute(...)