Update BoringSSL to 1c58648f14ed75f2a8cc3ae08897987d97f493ec (apple#239)

* Update patch-2-arm-arch.patch

* Update BoringSSL to 1c58648f14ed75f2a8cc3ae08897987d97f493ec

Update BoringSSL to 54858b63c1d886f6c8d903d4a4f594f1485de189 (apple#235)

Silence #file/#filePath warnings in XCTest (apple#228)

Motivation:

Swift 5.3 warns when `#file` is passed to a function expecting
`#filePath` even though the values are currently the same.

- swiftlang/swift#32445
- https://bugs.swift.org/browse/SR-12936
- https://bugs.swift.org/browse/SR-12934
- https://bugs.swift.org/browse/SR-13041

Modifications:

- Wrap `file` in parentheses to silence warnings.

Result:

- No warnings, uglier code

Allow double-setting the custom verify callback. (apple#224)

Motivation:

An unnecessary assertion prevented us double-setting the custom verify
callback. This had the effect of making the custom verify callback
unusable on Apple platforms in debug mode only. The actual code
tolerates a double-setting of the custom verify callback just fine, but
the assertion prevents it for no good reason.

Modifications:

- Removed an assertion.
- Added some tests to confirm it's all fine.

Result:

Users won't get crashes when they try to use the custom verify callback.
Fixes apple#223.

Enable X509_V_FLAG_TRUSTED_FIRST. (apple#220)

Motivation:

Unfortunately, while BoringSSL is mostly a fundamentally fantastic
library, it has inherited OpenSSL's X509 verifier. This verifier has a
number of issues, but its biggest problem is that it's simply not great
at verifying certificates!

Certificate chains are not so much "chains" as they are a single path
through a DAG. There are potentially many possible paths from a leaf
certificate to a set of roots. Some of these paths are not trusted, some
may be. BoringSSL's default verifier does not do a good job in some edge
cases because it prefers to use the intermediates provided by the client
when it could do a better job by using its own trust store.

As an example, consider the following three-certificate "chain":

CA A -- signs -- Intermediate CA B -- signs -- Leaf C

Imagine that CA A now becomes untrusted, either because it was revoked
or (more topically) because it expires. Imagine also that, in the
meantime, Intermediate CA B has become a fully-fledged CA, and has
re-issued its certificate as a self-signed root using the same key and
identifier.

The mistaken resolver may attempt to use as many certificates as
possible from the peer chain. If the peer chain is using the old,
now-replaced intermediate CA, this will cause BoringSSL to get confused:
it will build a chain that chains up to the intermediate CA, find the
old root in the trust store, and then complain that that root is expired
and fail the validation.

Instead, we want to ignore the intermediate CA B altogether! This is
because we now have a trusted root B', and if we use that then we'll
instantly get a valid chain and can move on.

This behaviour is controlled by a flag, `X509_V_FLAG_TRUSTED_FIRST`.
This flag is set by default in OpenSSL 1.1+. Sadly, it is not set by
default in BoringSSL. This patch resolves that issue.

Note that this issue only affects non-Apple platforms. On Apple
platforms we use the system resolver, which does not have this issue.

Modifications:

- Set `X509_V_FLAG_TRUSTED_FIRST`.
- Add a test to verify that flag is set.

Result:

We'll do a better (but still bad) job of building trust chains.

Resolve exclusivity violation on connection teardown. (apple#217)

Motivation:

When we're failing promises on channelInactive, we do so while holding
the write buffer mutably. This means that if anyone calls write() on us,
we'll explode, as we enqueue the write into the buffer.

Modifications:

- Rewrote the close loop to not hold the write buffer mutably.
- Added a regression test.

Result:

No crashes in production.

improve 5.3 docker setup (apple#214)

motivation: pin to 5.3 nighties 

changes: use swiftlang/swift:nightly-5.3-master-bionic instead of swiftlang/swift:nightly-master-bionic

Unwrapping timeout shouldn't close channel. (apple#206)

Motivation:

If the unwrapping timeout fires, rather than close the channel we should
just fire an error down the pipeline. This is in-line with standard NIO
behaviour, and allows users to opt-out of channel closure in the event
that they need it.

Modifications:

- Internal state modification to have different behaviour when
    unwrapping and closing timeout fires.

Result:

Users can control what happens if unwrapping times out.

universal bootstrap support (apple#185)

Replace deprecated function calls (apple#183)