Widen assertion on readEOF. (apple#453)

Motivation:

In Darwin it is possible for readEOF to be received before writable,
if we race connection teardown with registering for writable. See
apple#452 for a more in-depth
explanation.

Modifications:

Widened the assertion.

Result:

People's code won't go bang.

Don't provide promises when we don't care about results. (apple#437)

Motivation:

When we don't care about the result of an operation, we shouldn't provide
a promise.

While I'm here I also removed an unnecessary close() call in the
AcceptHandler: the close() would be called again almost immediately.

Modifications:

Removed a close() call.
Set `promise: nil` on a pair of close() calls.

Result:

Fewer promise allocations.

fix EventLoops that Bootstrap channel initialiser's call out on (appl…

…e#424)

Motivation:

Previously we were not running the (child/server)channelInitializers on the
event loop associated to the `Channel` we're initialising. Almost all
operations in there are pipeline modifications which are thread safe so
it presumably wasn't a massive correctness issue. However it's very
expensive to hop threads that often and it is also very unexpected. This
addresses this issue.

Modifications:

made all (child/server)channelInitializers run on the event loop that is
associated to their `Channel`

Result:

- more correctness
- less unexpected behaviour

Add ChannelCore.removeHandlers. (apple#408)

Motivation:

If ChannelPipeline.removeHandlers is internal it is extremely difficult
to implement a correct ChannelCore. For that reason, we should make it
available as an extension on ChannelCore.

This is a minor layering violation, but that's ok: ChannelCore and
Channel are not actually intended to be separate objects in most cases,
they are just separate for code clarity reasons.

Modifications:

Add ChannelCore.removeHandlers as a public method.

Result:

Easier to implement ChannelCore.

fix event loop hop between registration and activation of accepted ch…

…annels (apple#389)

Motivation:

Once again, we had an extra event loop hop between a channel
registration and its activation. Usually this shows up as `EPOLLHUP` but
not so for accepted channels. What happened instead is that we had a
small race window after we accepted a channel. It was in a state where
it was not marked active _yet_ and therefore we'd not read out its data
in case we received a `.readEOF`. That usually leads to a stale
connection. Fortunately it doesn't happen very often that the client
connects, immediately sends some data and then shuts the write end of
the socket.

Modifications:

prevent the event loop hop between registration and activation

Result:

will always read out the read buffer on .readEOF

fix some Swift 4.2 warnings (apple#374)

Motivation:

Warnings are bad.

Modifications:

Changed things that still work in 4.0/4.1 but are warnings in 4.2 to
improved versions.

Result:

less warnings on the upcoming 4.2

don't deliver events for unregistered fds (apple#341)

Motivation:

Since forever we had a major bug in the Selector: In this condition:

- kqueue/epoll had many events
- in one of the earlier events we unregister a Channel whose fd is on of
  the later events
- we subsequently (still in the same event loop tick) register a new
  channel which gets the same fd as the previously closed one

then we would deliver an event that was meant for a previous channel to
a newly opened one.

Thanks to @mcdappdev for hitting this bug, helping us debug it and also
providing a repeatedly working repro.

Modifications:

if during event delivery any fd gets unregistered, we stop delivering
the remaining events and rely on the selector to redeliver them
again next time.

Result:

we don't deliver events for previously closed channels to new ones.

Ensure correct ordering of promise notification when connect is still…

… pending. (apple#330)

Motivation:

When a pending connect is still in process and the Channel is closed we need to ensure we use the correct ordering when notify the promises and ChannelHandlers in the pipeline.

The ordering should be:

- Notify pending connect promise
- Notify close promise
- Call channelInactive(...)

Modifications:

- Correct ordering of notification
- Add unit test

Result:

Ensure correct ordering when connect is still pending

Don't call to user code before reconciling Channel state. (apple#310)

Motivation:

Callouts to user code allows the user to make calls that re-enter
channel code. In the case of channel closure, we could call out to the
user before the channel knew it was completely closed, which would
trigger a safety assertion (in debug mode) or hit a fatalError
(in release mode).

Modifications:

Reconciled channel state before we call out to user code.
Added a test for this case.

Result:

Fewer crashes, better channel state management.

Restore unary initializer for HTTPHeaders (apple#301)

Motivation:

The Swift compiler seems to get very nervous when variadic inits
are used for types that have constructors with optional values. In
general we're not worried about breaking downstream consumers'
extensions when we update our code, but in this case we break the
ability to conform HTTPHeaders to ExpressibleByDictionaryLiteral,
which is a bit annoying. See https://bugs.swift.org/browse/SR-7415
for more details.

For 1.5.0 we should conform HTTPHeaders ourselves, but until that
time we can restore anyone who was conforming HTTPHeaders to
ExpressibleByDictionaryLiteral by restoring the old unary initializer
and delegating it to the new one. This presents an effect that is
equivalent to the old behaviour, but is new.

As a side note, in general it's a bad idea to conform types that you
do not own to standard library protocols. NIO reserves the right to
add conformances to our types in any Semver Minor release, so having
that conformance in your own code risks breakage without a Semver
Major patch bump. Please be aware.

Modifications:

Restored the unary initializer for HTTPHeaders.

Result:

Less breakage, more happiness.