Correctly return from selector loop one a scheduled task is ready for processing

Motivation:

We use the nanoTime of the scheduledTasks to calculate the milli-seconds to wait for a select operation to select something. Once these elapsed we check if there was something selected or some task is ready for processing. Unfortunally we not take into account scheduled tasks here so the selection loop will continue if only scheduled tasks are ready for processing. This will delay the execution of these tasks.

Modification:

- Check if a scheduled task is ready after selecting
- also make a tiny change in NioEventLoop to not trigger a rebuild if nothing was selected because the timeout was reached a few times in a row.

Result:

Execute scheduled tasks on time.
[#2558] Define SO_REUSEPORT if not defined

Motivation:

Currently it is impossible to build netty on linux system that not define SO_REUSEPORT even if it is supported.

Modification:

Define SO_REUSEPORT if not defined.

Result:

Possible to build on more linux dists.
Fix inspector warnings

- Move the methods used by an inner class to the inner class
- Removal of various redundant things (throws, parens, ..)
Clean up HTTP/2 integration tests

Related pull request: #2481 written by @nmittler

Motivation:

Some tests were still sending requests from the test thread rather than
from the event loop.

Modifications:

- Modified the roundtrip tests to use a new utility Http2TestUtil to
  perform the write operations in the event loop thread.
- Modified the Http2Client under examples to write all requests in the
  event loop thread.
- Added HttpPrefaceHandler and its test which were missing.
- Fixed various inspector warnings

Result:

Tests and examples now send requests in the correct thread context.
Fix most inspector warnings

Motivation:

It's good to minimize potentially broken windows.

Modifications:

Fix most inspector warnings from our profile

Result:

Cleaner code
Fix the cruft produced from the refactoring

.. in 330404da07859f5dc2e2263da719ad4161f17d99
Removing unused Http2PrefaceHandler.

Motivation:

All of the functionality has been merged into
AbstractHttp2ConnectionHandler.

Modifications:

Removed the Http2PrefaceHandler/Test and all uses.

Result:

Code cleaned up a bit.
Changed Http2ClientConnectionHandler to print out the aggregated buffers content

Motivation:
When running the Http2Client the data returned from the server, the
"Hello World" string, is supposed to be printed but instead the following
is displayed:
Received message:

Modifications:
Use the aggregated buffer to print out.

Result:
The example now logs the correct data sent from the server:
Received message: Hello World
Fix the build timeout when 'leak' profile is active

Motivation:

AbstractByteBufTest.testInternalBuffer() uses writeByte() operations to
populate the sample data.  Usually, this isn't a problem, but it starts
to take a lot of time when the resource leak detection level gets
higher.

In our CI machine, testInternalBuffer() takes more than 30 minutes,
causing the build timeout when the 'leak' profile is active (paranoid
level resource detection.)

Modification:

Populate the sample data using ThreadLocalRandom.nextBytes() instead of
using millions of writeByte() operations.

Result:

Test runs much faster when leak detection level is high.
Let OkResponseHandler extend SimpleChannelInboundHandler

Motivation:

OkResponseHandler is the last handler in the pipeline of the HTTP CORS
example.  It is responsible for releasing all messages it handled.

Modification:

Extend SimpleChannelInboundHandler instead of ChannelHandlerAdapter

Result:

Fixed a leak
Split a JSON byte stream into JSON objects/arrays. Fixes #2536

Motivation:

See GitHub Issue #2536.

Modifications:

Introduce the class JsonObjectDecoder to split a JSON byte stream
into individual JSON objets/arrays.

Result:

A Netty application can now handle a byte stream where multiple JSON
documents follow eachother as opposed to only a single JSON document
per request.
Fix a buffer leak in JsonObjectDecoderTest
Fix an inspector warning in JsonObjectDecoder
[#2618] Introduce ChannelPromise.unvoid() and ChannelFuture.isVoid()

Motivation:

There is no way for a ChannelHandler to check if the passed in ChannelPromise for a write(...) call is a VoidChannelPromise. This is a problem as some handlers need to add listeners to the ChannelPromise which is not possible in the case of a VoidChannelPromise.

Modification:

- Introduce ChannelFuture.isVoid() which will return true if it is not possible to add listeners or wait on the result.
- Add ChannelPromise.unvoid() which allows to create a ChannelFuture out of a void ChannelFuture which supports all the operations.

Result:

It's now easy to write ChannelHandler implementations which also works when a void ChannelPromise is used.
[#2586] Use correct EventLoop to notify delayed bind failures

Motivation:

When a bind fails AbstractBootstrap will use the GlobalEventExecutor to notify the ChannelPromise. We should use the EventLoop of the Channel if possible.

Modification:

Use EventLoop of the Channel if possible to use the correct Thread to notify and so guaranteer the right order of events.

Result:

Use the correct EventLoop for notification
Make JsonObjectDecoder discard everything after stream corruption

Motivation:

There's no way to recover from a corrupted JSON stream. The current
implementation will raise an infinite exception storm when a peer sends
a large corrupted stream.

Modification:

Discard everything once stream corruption is detected.

Result:

Fixes a buffer leak
Fixes exception storm
Log the time taken for generating the initialSeedUniquifier

- Sometimes useful to know it how long it takes from the log, to make
  sure it's not something else that is blocking.
Reduce the perceived time taken to retrieve initialSeedUniquifier

Motivation:

When system is in short of entrophy, the initialization of
ThreadLocalRandom can take at most 3 seconds.  The initialization occurs
when ThreadLocalRandom.current() is invoked first time, which might be
much later than the moment when the application has started.  If we
start the initialization of ThreadLocalRandom as early as possible, we
can reduce the perceived time taken for the retrieval.

Modification:

Begin the initialization of ThreadLocalRandom in InternalLoggerFactory,
potentially one of the firstly initialized class in a Netty application.

Make DefaultChannelId retrieve the current process ID before retrieving
the current machine ID, because retrieval of a machine ID is more likely
to use ThreadLocalRandom.current().

Use a dummy channel ID for EmbeddedChannel, which prevents many unit
tests from creating a ThreadLocalRandom instance.

Result:

We gain extra 100ms at minimum for initialSeedUniquifier generation.  If
an application has its own initialization that takes long enough time
and generates good amount of entrophy, it is very likely that we will
gain a lot more.
Fix another buffer leaks in JsonObjectDecoderTest