The WebRTC changes in https://codereview.webrtc.org/1857163003 pulled in the BoringSSL dependency for Chromium for iOS (since use_openssl=0 for iOS in Chromium, while it's always 1 in WebRTC, even for iOS).

This made the iOS GN bots fail when attempting to roll this in with https://codereview.chromium.org/1862763003/. The ios_rel_device_gn to errors due to duplicate symbols since it tried to link with both OpenSSL and BoringSSL: 
https://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_gn/builds/14835/steps/compile/logs/stdio
snippet: 
4880/4887] STAMP obj/sync/sync_unit_tests.stamp
FAILED: /b/build/goma/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang++ -arch armv7 -isysroot /Applications/Xcode7.0.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.0.sdk -stdlib=libc++ -miphoneos-version-min=9.0 -o "./gen/ios/chrome/ios_chrome_unittests" -Wl,-filelist,"./gen/ios/chrome/ios_chrome_unittests.rsp"  -framework UIKit -framework CoreFoundation -framework CoreGraphics -framework CoreText -framework Foundation -framework CFNetwork -framework MobileCoreServices -framework Security -framework SystemConfiguration -lresolv -lsqlite3 -framework ImageIO -framework WebKit -framework Accelerate -framework CoreLocation -framework QuartzCore -lz
duplicate symbol _HMAC_Init in:
    obj/third_party/nss/nss_static/alghmac.o
    obj/third_party/boringssl/boringssl/hmac.o
duplicate symbol _HMAC_Update in:
    obj/third_party/nss/nss_static/alghmac.o
    obj/third_party/boringssl/boringssl/hmac.o
duplicate symbol _MD5_Update in:
    obj/third_party/nss/nss_static/md5.o
    obj/third_party/boringssl/boringssl/md5.o
duplicate symbol _SHA1_Update in:
    obj/third_party/nss/nss_static/sha_fast.o
    obj/third_party/boringssl/boringssl/sha1.o
duplicate symbol _SHA256_Update in:
    obj/third_party/nss/nss_static/sha512.o
    obj/third_party/boringssl/boringssl/sha256.o
duplicate symbol _SHA224_Update in:
    obj/third_party/nss/nss_static/sha512.o
    obj/third_party/boringssl/boringssl/sha256.o
duplicate symbol _SHA384_Update in:
    obj/third_party/nss/nss_static/sha512.o
    obj/third_party/boringssl/boringssl/sha512.o
duplicate symbol _SHA512_Update in:
    obj/third_party/nss/nss_static/sha512.o
    obj/third_party/boringssl/boringssl/sha512.o
ld: 8 duplicate symbols for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)


The mystery in all this is how the GYP build can pass, since what https://codereview.webrtc.org/1857163003
actually did was to move BoringSSL stuff out of the condition for the GN build, something that happened a while
ago for GYP in https://codereview.webrtc.org/1351503004). When that was done, the GYP build should have hit the
same error when rolling WebRTC past that point in Chromium DEPS, but it didn't.

AFAICT the GYP build has the same dependency on BoringSSL: src/jingle/jingle.gyp -> src/third_party/libjingle/libjingle.gyp -> src/third_party/webrtc/base/base.gyp -> src/third_party/boringssl/boringssl.gyp.

Since I'm unable to figure this out, I'm going to revert the problematic part of https://codereview.webrtc.org/1857163003
to unblock rolling, since the M51 branch point is closing in.