Add support for proxying in `WebsocketClient`

This patch was authored by @rnro and released by @0xTim.

Added support for TLS and plain text proxying of Websocket traffic.

• In the TLS case a CONNECT header is first sent establishing the proxied traffic.

• In the plain text case the modified URI in the initial upgrade request header indicates to the proxy server that the traffic is to be proxied.

• Use NIOWebSocketFrameAggregator to handle aggregating frame fragments. This brings with it more protections e.g. against memory exhaustion.

• Accompanying config has been added to support this change.

This change also includes some performance gains by reducing the allocation and copies necessary to send ByteBuffer and ByteBufferView through WebSocket.send.

• Sending ByteBuffer or ByteBufferView doesn’t require any allocation or copy of the data. Sending a String now correctly pre allocates the ByteBuffer if multibyte characters are present in the String.

• Remove custom random websocket mask generation which would only generate bytes between UInt8.min..<UInt8.max, therefore excluding UInt8.max i.e. 255.

Do not add a `Content-Type` header to the HTTP upgrade request

This patch was authored by @fumoboy007 and released by @0xTim.

⚠️ WARNING: This release removes the hard-coded content-type header from the upgrade request. If you were relying on this you'll need to manually add it now, but since there's no body it shouldn't be required

Some WebSocket servers use the Content-Type header to determine which serialization format to use for its WebSocket messages. However, HTTPInitialRequestHandler adds a hard-coded Content-Type: text/plain; charset=utf-8 header to the WebSocket client’s HTTP upgrade request, so the client cannot customize the header value.

Given that the HTTP upgrade request body is empty, there is no need for HTTPInitialRequestHandler to add the Content-Type header. This will allow the client to add their own, if desired.

Fixes #126.

Remove use of NIOAtomics in favor of Atomics

This patch was authored by @MahdiBM and released by @0xTim.

The Problem

Starting with SwiftNIO 2.41.0, NIOAtomics is deprecated in favor of Atomics.
This produces a warning if you use SwiftNIO 2.41.0 or higher.

Modifications

This PR add a dependency to Atomics to change the only use of NIOAtomics to Atomics, and suppress the warning.

What Warning?!

path/to/package/.build/checkouts/websocket-kit/Sources/WebSocketKit/WebSocketClient.swift:40:22: warning: 'NIOAtomic' is deprecated: please use ManagedAtomic from https://github.com/apple/swift-atomics instead
    let isShutdown = NIOAtomic.makeAtomic(value: false)
                     ^

Add support for NIOTransportServices

This patch was authored by @PopFlamingo and released by @0xTim.

This PR intends to fix #29 by using the NIOTransportServices library

Don't use IP addresses for SNI

This patch was authored by @olivernyc and released by @0xTim.

TLS forbids the use of literal IPv4 and IPv6 addresses in server name indication. However, websocket-kit passes IP addresses to NIOSSLClientHandler as serverHostname, which triggers an error when the underlying validateSNIServerName is called. See apple/swift-nio-ssl#380 for more context.

This PR adds a do / catch statement to pass nil for serverHostname in case of the specific cannotUseIPAddressInSNI error, which allows for secure connections to IP addresses.

Enable compilation on iOS

This patch was authored by @makleso6 and released by @0xTim.

This adds experimental support for building WebsocketKit on iOS from iOS 11 onwards

Closing #117

Make sure onPing is called and account for control frames being able to be interspersed with message fragments

This patch was authored by @tkrajacic and released by @0xTim.

Control frames can appear in the middle of fragmented messages. Therefor they must not be part of the frameSequence. Also expose the frame data of the control frames, as that might be usable application data.

Before this PR, onPing was never called at all.

Update Supported Swift Versions

This patch was authored and released by @0xTim.

This removes support for Swift 5.2 and Swift 5.3, making Swift 5.4 the earliest supported version as announced

Remove content length header on initial handshake

This patch was authored by @GNMoseke and released by @0xTim.

This removes the content-length: 0 header being automatically applied to outgoing websocket handshakes.

As per RFC 7230 Section 3.3.2:

A user agent SHOULD NOT send a
Content-Length header field when the request message does not contain
a payload body and the method semantics do not anticipate such a
body.

This was causing issues with certain cloud providers, most notably Google Cloud Run, that would force close the websocket as soon as data was received from a client.

Add support for async/await

This patch was authored by @madsodgaard and released by @0xTim.

Adds support for async/await in WebsocketKit.

Partially fixes: vapor/vapor#2641