Allow promises to be completed with a `Result<Value, Error>` (apple#1124

)

Motivation:

When dealing with `Result` types and promises it is inconvenient having to
switch over the result in order to succeed or fail a promise.

Modifications:

- Allow promises to be completed with a `Result<Value, Error>` directly.
- Added tests.

Result:

Promises are easier to fulfill with `Result` types.

BaseSocketChannel: accept immediately closed socket (apple#1121)

Motivation:

In the grpc-swift test suite, we saw a case where the server would
always immediately close the accepted socket. This lead NIO to misbehave
badly because kqueue would send us the `readEOF` before the `writable`
event that finishes an asynchronous `connect`.

What happened is that we just dropped the `readEOF` on the floor so we
would never actually tell the user if the channel ever went away.

Modifications:

Only register for `readEOF` after becoming active.

Result:

- we're happy with servers that immediately close the socket

Remove `cpp_magic.h` import and ancient Clang compatibility hack from…

… `CNIOAtomics.h` (apple#1111)

The inclusion of `cpp_magic.h` in `CNIOAtomics.h` is unnecessary and pollutes the namespace of anyone else importing the header. NIO now also requires Swift 5, which itself will not be built with a Clang too old to understand `_Nonnull`. Note: Removing the extra import of cpp-magic.h required moving it to the src/ directory to avoid complaints about its inclusion (or lack thereof) in the module's umbrella header.

Fail promise in MessageToByteHandler write error cases (apple#1096)

* Fail promise in MessageToByteHandler write error cases

* Add test case for MessageToByteHandler failing write promises

fix double remove of handlers (apple#1091)

* fix double remove of handlers

Motivation:

Previously, it was possible that a handler was removed twice: Once by
Channel teardown and another time by a user-trigger removal that wasn't
instantaneous. This racy situation can happen in the real world. NIO
behaved wrongly in two ways:

1. we would call `handlerRemoved` twiced
2. ByteToMessageHandler would fail an assertion about the current
   removal state

Modifications:

- Only call `handlerRemoved` when the handler actually gets removed.
- Fix the assertion.

Result:

fewer bugs

* Update Sources/NIO/ChannelPipeline.swift

Co-Authored-By: Cory Benfield <lukasa@apple.com>

Make pipeline handler behave better when removed (apple#1080)

Motivation:

The HTTPServerPipelineHandler is removed from pipelines in many cases,
but the most common case is over upgrade. While the handler is
removable, it doesn't make any effort to ensure that it leaves the
pipeline in a sensible state, which is pretty awkward.

In particular, there are 3 things the pipeline handler may be holding
on to that can lead to damage. The first is pipelined requests: if there
are any, they should be delivered, as the user may be deliberately
allowing pipelining.

The second thing is read() calls. The HTTPServerPipelineHandler exerts
backpressure on clients that aggressively pipeline by refusing to read
from the socket. If that happens, and then the handler is removed from
the channel, it will "forget" to restart reading from the socket on the
way out. That leaves the channel quietly in a state where no reads will
occur ever again, which is pretty uncool.

The third thing is quiescing. The HTTPServerPipelineHandler catches
quiescing events and allows them to deliver a response before closing a
connection. If that has happened when the pipeline handler is removed,
it should fall back to the behaviour as though it were not there.

Modifications:

- Added a handlerRemoved implementation to play event state that should
    be replayed.
- Added a channelInactive implementation to drop data.

Result:

More graceful handler removal.

5.1-DEVELOPMENT-SNAPSHOT-2019-07-19-a (apple#1079)

HTTPDecoder: no error on unclean EOF on upgrade (apple#1063)

Motivation:

Previously we thought that if we have some bytes left that belong to an
upgraded protocol, we should deliver those as an error. This is
implemented on `master` but not in any released NIO version.
However, no other handler sends errors on unclean shutdown, so it feels
wrong to do it in this one very specific case (EOF on inflight upgrade
with data for the upgraded protocol)

Modifications:

Remove the error again.

Result:

Less behaviour change to the last released NIO version.

enable TCP_NODELAY by default (apple#1020)

Motivation:

Networking software like SwiftNIO that always has explicit flushes
usually does not benefit from having TCP_NODELAY switched off. The
benefits of having it turned on are usually quite substantial and yet we
forced our users for the longest time to enable it manually.

Quite a bit of engineering time has been lost finding performance
problems and it turns out switching TCP_NODELAY on solves them
magically.

Netty has made the switch to TCP_NODELAY on by default, SwiftNIO should
follow.

Modifications:

Enable TCP_NODELAY by default.

Result:

If the user forgot to enable TCP_NODELAY, their software should now be
faster.

replace redundant commands in docker-compose files with generic one (a…

…pple#1010)

Motivation: keep it DRY

Modifications: move redundant commands from 18-04-5.0 and 16.04-5.1 to the generic task definitions