BREAKING: Re-implement SwiftyRequest on NIO async-http-client

[djones6]

This PR re-implements the SwiftyRequest API on top of the Swift-NIO based async-http-client, and adds client certificate support.

This is based on work done by @Andrew-Lees11 described in #58, including:

• All JSON code has been removed and replaced with Codable
• ~HTTPMethod.swift has been removed and replaced with the NIOHTTP1.HTTPMethod~
  • update: HTTPMethod remains, and is now convertible to/from NIOHTTP1.HTTPMethod.
• ~headerParameters has changed from a [String:String] to HTTPHeaders~
  • update: headerParameters remains [String:String] with mapping under the covers
• response() now returns Result<HTTPClient.Response, RestError> instead of (Data?, HTTPURLResponse?, Error?)
• RestResponse now represents an HTTPClient.Response that is generic over the body instead of an HTTPURLResponse with the result of the body.
• Credentials input has been converted to be an extensible struct.
• RestError now represents any error that could be returned from a request attempt, including errors relating to malformed URLs or HTTPClientErrors. So strictly speaking, it's not just a REST error, but I'd prefer to retain the naming.
  • RestError now has a convenience function for retrieving the response body data when the error represents an unsuccessful request.
• RestRequest.init parameter containsSelfSignedCert has been renamed to insecure to more accurately reflect what it means, though I've retained (and deprecated) the current naming.

In addition, I have implemented Client Certificate support for 2-way SSL. This is non-functional in SwiftyRequest 2.x. This initial support provides a convenience API for consuming a certificate (and its private key) from a PEM-formatted file, String, Data or [UInt8]. There is also support for supplying the raw NIOSSLCertificate and NIOSSLPrivateKey which allows complete freedom of the data sources, if required. We could add additional convenience APIs for other popular file formats in the future.

As well as refactoring the existing tests for the new API, I've added a Client Certificate test that downloads a valid certificate from https://badssl.com/download/ and then presents it to https://client.badssl.com. The certificate must be downloaded by the test because it may be reissued as it expires. The password for the certificate's key is hard-coded into the test - I'm assuming that it will not change over time.

Effect of breaking API changes

https://github.com/IBM-Swift/KituraKit/pull/53 demonstrates the extent of changes required to an application to migrate to the new API.

Motivation and Context

Resolves #58 and #57

[ianpartridge]

FYI @artemredkin @weissi

[weissi]

awesome!

[djones6]

@ianpartridge @weissi This currently builds against 1.0.0-alpha.3 but I expect it'll break as more breaking changes are tagged. To avoid this we could hard-code a .exact version, or wait until 1.0.0 is ready. What do you think?

I'd be inclined to do the former, as updating to newer releases of the client should be straightforward. However, we do expose the HTTPClient.Request and HTTPClient.Cookie types as part of RestResponse, so those might change (though I'd imagine, not significantly).

[weissi]

@djones6 I think that is sensible. I would like if we tried to slow down the breakages but I can understand if you want to .exact pin it until it reaches 1.0.0

[djones6]

@ianpartridge Example of changes required to KituraKit to adopt the new API: https://github.com/IBM-Swift/KituraKit/pull/53/commits/53ea6e2357aac4951ddefda281e2caafe3c8126b

[weissi]

@djones6 btw, beta 4 landed earlier. It should be API compatible with beta 3, although there are some deprecations (with very straightforward fixes)