Don't log to file in CI (grpc#1129) Motivation: The connection backoff interop test periodically fails in CI when tearing down. In CI we currently capture the logs to file, this isn't too sensible: we can't access them from Travis. Modifications: - Don't log interop test output to file in CI - Print all thrown errors in the connection backoff interop test Result: Some visibilitiy into why the test is occasionally failing

Move the pcap example into Source/Examples/ (grpc#1119) Motivation: The PCAP example depends on swift-nio-extras. Since grpc-swift now depends on swift-nio-extras (and we have target based dependency resolution) the example can live in-source with other examples. Modifications: - Move Examples/PCAPExample to Source/Examples/PacketCapture. - Make it a target in the GRPC package, rather than its own package. Result: Easier to avoid bit-rot.

Added support for NIOSSLCustomVerificationCallback for client connect… …ion (grpc#1107) This allows client apps to perform SSL Public Key Pinning, or override the certificate verification logic

Simplify client transport actions and state representation (grpc#1080) Motivation: The representation of state and any outcomes as a result of changing state in 'ClientTransport' is generic over the request and response types. This turns out to be a non-trivial performance hit. Modifications: - Split up state actions into per-function actions - Move state out of 'ClientTransport' Result: - A 5% decrease in instruction for the 'unary_10k_small_requests' benchmark (note that this change is client only and yet the benchmark includes instructions for client and server).

Use ALPN to determine what sort of connection we've accepted (grpc#1055) Motivation: To determine whether we're dealing with gRPC or gRPC Web (i.e. HTTP/2 or HTTP/1) the first bytes received on a new connection are parsed. When TLS is enabled and ALPN is supported there's no need to do this: we will be informed about the protocol we negotiated with our peer and therefore how to configure the channel. We also never enforced that the protocol negotiated via ALPN was used! Modifications: - Add a 'GRPCServerPipelineConfigurator' handler to supersede the 'HTTPProtocolSwitcher'. The new handler will use either ALPN and fall back to parsing the incoming bytes. - The parsing behavior is slightly different to that of 'HTTPProtocolSwitcher' in that we only read off enough bytes for the HTTP/2 connection preface, or enough bytes to parse an HTTP/1 request line (rather than reading the whole buffer as a string and processing that). - Added a server configuration option to disable ALPN being required. - Added tests. Result: - Server pipeline configuration is driven by ALPN, falling back to parsing. - ALPN is enforced on the server (partially resolving grpc#1042)

Fix 0.9.1 Carthage Support on Xcode 12.2 (grpc#1053) * workaround for fix-carthage script * xcode12 pre-actions cause error at swift package resolve by some env values

Add an option to set 'certificateVerification' to the client builder (g… …rpc#980) Motivation: We allow users to set the `certificateVerification` if they configure their client directly using `ClientConnection.Configuration` but not via the builder API. Modifications: - Add `withTLS(certificateVerification:)` to the client connection builder. (The same option is already available on the server builder) Result: Users can set the certificate verification mode on the client builder.

Update NIO version to 2.22.0 and NIOHTTP2 to 1.14.1. (grpc#954) Motivation: SwiftNIO 2.21.0 inlcudes a fast-path for writing `Data` into a `ByteBuffer`, and SwiftNIO HTTP/2 1.14.0 contains a `reserveCapacity` for `HPACKHeaders`. Modifications: - Replace a few occurrences of `writeBytes` with the new `writeContiguousBytes` instead. - Reserve the capacity upfront when constructing request headers - Stop using a deprecated function Result: - Perf win when serializing and writing protobuf messages into a buffer

Update to SwiftNIO HTTP/2 1.13.0 (grpc#922) Motivation: The multiplexer from SwiftNIO HTTP/2 required that the first write on each stream matched the order in which the streams were created. Violating this led to a connection error; all in-flight and subsequent RPCs on that connection would fail. Some of our users noticed this (grpc#912). SwiftNIO HTTP/2 recently reworked the API around how streams are created: HTTP/2 stream channels are no longer created with a stream ID and now deliver the frame payload to the channel pipeline rather than the entire HTTP/2 frame. This allows for a stream ID to be assigned to a stream when it attempts to flush its first write, rather than when the stream is created. Modifications: - Increase the minimum HTTP/2 version to 1.13.0 - Move away from deprecated APIs: this required changing the inbound-in and outbound-out types for `_GRPCClientChannelHandler` as well as a few smaller changes elsewhere. Result: - RPCs can be created concurrently without fear of violating any stream ID ordering rules - Resolves grpc#912

NetworkPreference.best should be POSIX on older platforms (grpc#896) Motivation: While NetworkPreference.best was supposed to abstract away the choice of exactly which event loop would be used, on older Darwin platforms it would actually lead to runtime crashes as it would try to use an implementation it didn't have. Modifications: Have .best's .implementation fall back to POSIX on older platforms. Result: Fewer crashes on older platforms.