Added support for NIOSSLCustomVerificationCallback for client connection

[franck-clement-ug]

Hi,

This PR adds the ability for client connections to override the certificate verification logic implemented in nio-ssl.

The main goal is to allow client apps to perform their own certificate verification logic, such as SSL public key pinning.
Nio-ssl provide this feature as described here: nio-ssl-issue-25
But I wasn't able to use it through grpc-swift because the NIOSSLCustomVerificationCallback is not accessible when initializing a secure ClientConnection.

I exposed a NIOSSLCustomVerificationCallback property in ClientConnection.Configuration struct and provided a ClientConnection.Builder func as well.

Usage example for client public key pinning

let myPublicKey = Array(Data(base64Encoded: """
.... (Your base64 encoded public key)
""", options: .ignoreUnknownCharacters)!)

ClientConnection.secure(group: PlatformSupport.makeEventLoopGroup(loopCount: 1))
            .withTLSCustomVerificationCallback({ cert, eventLoopVerification in
                // Extract the leaf certificate's public key,
                // then compare it to the one you have.
                if let leaf = cert.first,
                   let publicKey = try? leaf.extractPublicKey() {

                    if let certSPKI = try? publicKey.toSPKIBytes(),
                       myPublicKey == certSPKI {
                        eventLoopVerification.succeed(.certificateVerified)
                    } else {
                        eventLoopVerification.fail(NIOSSLError.unableToValidateCertificate)
                    }
                } else {
                    eventLoopVerification.fail(NIOSSLError.noCertificateToValidate)
                }
            })
            .connect(host: host, port: port)

This PR + the example above should resolve #723 and resolve #1104

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Franck CLEMENT (1e7dff0)

[glbrntt]

Thanks for the PR, I've left some initial comments inline. You'll need to reformat the code to be consistent with the rest of the project (running ./scripts/format.sh should do it). We'll also need a test for this; you should be able to use the ClientTLSFailureTests as a starting point.

[franck-clement-ug]

@glbrntt Thank you for the detailed comments, they all make a lot of sense, and I fixed them.
I also added a test when the validation logic is forced to fail within the customVerificationCallback.

[glbrntt]

Thanks @franck-clement-ug this looks good, just one naming nit to fix.

[glbrntt]

This looks good to me -- assuming CI passes -- thanks @franck-clement-ug!