[#2234] Use QueryStringDecoder.decodeComponent to decode url-encoded data instead of Java's URLDecoder.

Motivation:
Previously, we used URLDecoder.decode(...) to decode url-encoded data. This generates a lot of garbage and takes a considerable amount of time.

Modifications:
Replace URLDecoder.decode(...) with QueryStringDecoder.decodeComponent(...)

Result:
Less garbage to GC and faster decode processing.
Make sure the local / remote InetSocketAddres can be obtained. Part of [#2262]

Motivation:
Make sure the remote/local InetSocketAddress can be obtained correctly

Modifications:
Set the remote/local InetSocketAddress after a bind/connect operation was performed

Result:
It is possible to still access the informations even after the fd became invalid. This mirror the behaviour of NIO.
Allow specifying `SelectorProvider` when constructing an NIO channel #2311

Motivation:

At the moment we use the system-wide default selector provider for this invocation of the Java virtual machine when constructing a new NIO channel, which makes using an alternative SelectorProvider practically useless.
This change allows user specify his/her preferred SelectorProvider.

Modifications:

Add SelectorProvider as a param for current `private static *Channel newSocket` method of NioSocketChannel, NioServerSocketChannel and NioDatagramChannel.
Change default constructors of NioSocketChannel, NioServerSocketChannel and NioDatagramChannel to use DEFAULT_SELECTOR_PROVIDER when calling newSocket(SelectorProvider).
Add new constructors for NioSocketChannel, NioServerSocketChannel and NioDatagramChannel which allow user specify his/her preferred SelectorProvider.

Result:

Now users can specify his/her preferred SelectorProvider when constructing an NIO channel.
Implement EventExecutor.parent() in AbstractEventExecutor

Motivation:

EventExecutor.parent() and EventLoop.parent() almost always return a constant parent executor.  There's not much reason to let it implemented in subclasses.

Modifications:

- Implement AbstractEventExecutor.parent() with an additional contructor
- Add AbstractEventLoop so that subclasses extend AbstractEventLoop, which implements parent() appropriately
- Remove redundant parent() implementations in the subclasses
- Fix inspector warnings

Result:

Less duplication.
Use common non-magic number for shutdown timeout

Motivation:

AbstractEventExecutor and AbstractEventExecutorGroup have hard-coded magic timeout numbers.  They should have the same timeout numbers, but it's easy to break that rule because they are hard-coded in each place.

Modifications:

Add package private constants to AbstractEventExecutor and let AbstractEventExecutorGroup use them.

Result:

Single timeout change affects two classes.
Make DefaultEventExecutor usable by users.

Motivation:

There's no reason to keep our users from using DefaultEventExecutor directly.  It should be actually very useful to them.

Modifications:

Make DefaultEventExecutor public and add useful public constructors.

Result:

DefaultEventExecutor got usable by anyone, yielding more value as a generic library.
Replace LocalEventLoopGroup with DefaultEventLoopGroup

Motivation:

LocalEventLoopGroup and LocalEventLoop are not really special for LocalChannels.  It can be used for other channel implementations as long as they don't require special handling.

Modifications:

- Add DefaultEventLoopGroup and DefaultEventLoop
- Deprecate LocalEventLoopGroup and make it extend DefaultEventLoopGroup
- Add DefaultEventLoop and remove LocalEventLoop
- Fix inspector warnings

Result:

- Better class names.
Add EventExecutor.children() in favor of iterator()

Motivation:

EventExecutor.iterator() is fixed to return Iterator<EventExecutor> and there's no way to change that as long as we don't extend Iterable.  However, a user should have a way to cast the returned set of executors painlessly.  Currently, it is only possible with an explicit cast like (Iterator<NioEventLoop>).

Modifications:

Instead, I added a new method called 'children()' which returns an immutable collection of child executors whose method signature looks like the following:

    <E extends EventExecutor> Set<E> children();

Result:

A user can now do this:

    Set<NioEventLoop> loops = group.children();
    for (NioEventLoop l: loops) { ... }

Unfortunately, this is not possible:

    for (NioEventLoop l: group.children()) { ... }

However, it's still a gain that a user doesn't need to down-cast explicitly and to add the '@SuppressWarnings` annotation.
Update the Javadoc of ChannelHandler and ChannelHandlerContext

Motivation:

It's out of date and it has broken links, etc.

Modifications:

Backport the fixes from master (132af3a485015ff912bd567a47881814d2ce1828)

Result:

Better Javadoc
Correct the return type of MultithreadEventLoopGroup.newChild()

Motivation:

MultithreadEventLoopGroup.newChild() does not override MultithreadEventExecutorGroup.newChild() which returns EventExecutor.  MultithreadEventLoopGroup.newChild() should never return an EventExecutor, so this is incorrect.

Modifications:

Override MultithreadEventLoopGroup.newChild() so that it returns EventLoop

Result:

Correct API
User-definable thread model via ChannelHandlerInvoker

Motivation:

While the default thread model provided by Netty is reasonable enough for most applications, some users might have a special requirement for the thread model.  Here are a few examples:

- A user might want to invoke handlers from the caller thread directly, assuming that his or her application is completely asynchronous and does not make any invocation from non-I/O thread.  In this case, the default invoker implementation will only add the overhead of checking if the current thread is an I/O thread or not.
- A user might want to invoke handlers from different threads depending on the type of events flexibly.

Modifications:

- Backport 132af3a485015ff912bd567a47881814d2ce1828 which is a fix for #1912
  - Add a new interface called 'ChannelHandlerInvoker' that performs the invocation of event handler methods.
  - Add pipeline manipulation methods that accept ChannelHandlerInvoker
- The differences from the original commit:
  - Separated the irrelevant changes out
  - Channel.eventLoop is null until the registration is complete in this branch, so Channel.Unsafe.invoker() doesn't work before registration.
  - Deregistration is not gone in this branch, so the methods related with deregistration were added to ChannelHandlerInvoker
[#2339] Reduce memory usage in ProtobufVarint32LengthFieldPrepender

Motivation:

Reduce memory usage in ProtobufVarint32LengthFieldPrepender.

Modifications:

Explicit set the buffer size that is needed for the header (between 1 and 5 bytes).

Result:

Less memory usage in ProtobufVarint32LengthFieldPrepender.
Deleting redundant needsFlush boolean

Motivation:

In ChunkedWriteHandler, there is a redundant variable that servers
no purpose. It implies that under some conditions you might not want
to flush.

Modifications:

Removed the variable and the if condition that read it. The boolean
was always true so just removing the if statement was fine.

Result:

Slightly less misleading code.
Adding origins whitelist support for CORS

Motivation:
Currently the CORS support only handles a single origin, or a wildcard
origin. This task should enhance Netty's CORS support to allow multiple
origins to be specified. Just being allowed to specify one origin is
particulary limiting when a site support both http and https for
example.

Modifications:
- Updated CorsConfig and its Builder to accept multiple origins.

Result:
Users are now able to configure multiple origins for CORS.

[https://github.com/netty/netty/issues/2346]
[#2349] Correctly handle cancelled ChannelPromise in DefaultChannelHandlerContext

Motivation:
At the moment an IllegalArgumentException will be thrown if a ChannelPromise is cancelled while propagate through the ChannelPipeline. This is not correct, we should just stop to propagate it as it is valid to cancel at any time.

Modifications:
Stop propagate the operation through the ChannelPipeline once a ChannelPromise is cancelled.

Result:
No more IllegalArgumentException when cancel a ChannelPromise while moving through the ChannelPipeline.
[#2358] SslHandler.safeClose(...) may not notify the ChannelPromise

Motivation:
In SslHandler.safeClose(...) we attach a ChannelFutureListener to the flushFuture and will notify the ChannelPromise which was used for close(...) in it. The problem here is that we only call ChannelHandlerContext.close(ChannelPromise) if Channel.isActive() is true and otherwise not notify it at all. We should just call ChannelHandlerContext.close(ChannelPromise) in all cases.

Modifications:
Always call ChannelHandlerContext.close(ChannelPromise) in the ChannelFutureListeiner

Result:
ChannelPromise used for close the Channel is notified in all cases
[#2361] Native.epollCreate(...) fails on systems using a kernel < 2.6.27 / glibc < 2.9

Motivation:
Native.epollCreate(...) fails on systems using a kernel < 2.6.27 / glibc < 2.9 because it uses epoll_create1(...) without checking if it is present

Modifications:
Check if epoll_create1(...) exists abd if not fall back to use epoll_create(...)

Result:
Works even on systems with kernel < 2.6.27 / glibc < 2.9
[#2362] AbstractChannel.AbstractUnsafe.write(...) is slow

Motivation:
At the moment we do a Channel.isActive() check in every AbstractChannel.AbstractUnsafe.write(...) call which gives quite some overhead as shown in the profiler when you write fast enough. We can eliminate the check and do something more smart here.

Modifications:
Remove the isActive() check and just check if the ChannelOutboundBuffer was set to null before, which means the Channel was closed. The rest will be handled in flush0() anyway.

Result:
Less overhead when doing many write calls
[#2359] EpollSocketChannel.remoteAddress0() is always null on accepted EpollSocketChannels

Motivation:
EpollSocketChannel.remoteAddress0() is always null on accepted EpollSocketChannels as we not set it excplicit.

Modifications:
Correctly retrieve the local and remote address when accept new channel and store it

Result:
EpollSocketchannel.remoteAddress0() and EpollSocketChannel.localAddress0() return correct addresses
[#2363] SelectedSelectionKeySet may hold strong reference to SelectionKey after Channel is closed

Motivation:
Because we not null out the array entry in the SelectionKey[] which is produced by SelectedSelectionKeySet.flip() we may end up with a few SelectionKeyreferences still hanging around here even after the Channel was closed. As these entries may be present at the end of the SelectionKey[] which is never updated for a long time as not enough SelectionKeys are ready.

Modifications:
Once we access the SelectionKey out of the SelectionKey[] we directly null it out.

Result:
Reference can be GC'ed right away once the Channel was closed.