Removing crypto/third_party/nss/ and removing crypto _win files

third_party/boringssl/boringssl.gyp

Index: third_party/boringssl/boringssl.gyp
diff --git a/third_party/boringssl/boringssl.gyp b/third_party/boringssl/boringssl.gyp
index f1a9384da09d1ac7419541429d733d819f2f97bf..4b75d16037f4ee1864826067773223fe97ceef31 100644
--- a/third_party/boringssl/boringssl.gyp
+++ b/third_party/boringssl/boringssl.gyp
@@ -8,6 +8,50 @@
   ],
   'targets': [
     {
+      'target_name': 'boringssl_nacl_win64',
+      'type': '<(component)',
+      'sources': [
+        '<@(boringssl_crypto_sources)',
+        '<@(boringssl_ssl_sources)',

[Ryan Sleevi, 2016/04/28 21:06:58]

This seems like a way bigger size hit to NaCl; we should definitely have a NaCl
owner review this. From discussion with David, I thought the plan was to gut
'just enough' to do HMAC.

[svaldez, 2016/04/28 21:14:50]

I *think* that the static linker will just drop the right things.

[Ryan Sleevi, 2016/04/28 21:29:59]

Well, you're building as <(component), so it can't drop exported symbols, even
if unused.

[davidben, 2016/04/28 21:35:44]

Only in the shared library build, right? The static library build will still
drop things freely.

I don't have hugely strong opinions. The static library version makes the build
less fragile and makes updating BoringSSL less of a pain. At the same time, the
list of files that make up HMAC-SHA-256 probably wouldn't change much and
relying on the static linker for binary size means we need to be watching
nacl_win64's binary size? (Are we? We should...) I am generally a fan of using
the static linker though. Fewer build configs to fuss with and maintain.

Though note that we have rely on the static linker slightly anyway. The method
tables for all the digests in BoringSSL are, right now, kept in the same
file[*]. I believe Windows builds with the equivalent of -ffunction-sections (I
forget the flag, but I recall looking this up at one point), so it should work.
Worth verifying though.

[*] Of course, there's no reason that can't change.

[Ryan Sleevi, 2016/04/29 00:12:54]

I believe the nacl helper is built as a DLL; but definitely, we'll want to find
a "NaCl build guru" to review.

I'm all in favor of KISS if necessary, but every other NaCl change I saw go by
tried to include narrow inclusions, rather than looking at specific exclusions.

[davidben, 2016/04/29 00:43:15]

Looks like it's built as an executable, unless there's magic elsewhere to make
that a DLL.
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/chrome_exe....

If it were a DLL, the value of <(component) would still be the same. It's one
set of build variables and two targets. We'd be building boringssl_crypto_win64
as a static library (notably NOT exporting the symbols) and then linking that
into a dll, which is what we want. Whether, in that case, the linker would drop
all sections unreachable from *any* exported symbol, I'm not sure.

+      ],
+      'defines': [
+        'BORINGSSL_IMPLEMENTATION',
+        'BORINGSSL_NO_STATIC_INITIALIZER',
+        'OPENSSL_NO_ASM',
+        'OPENSSL_SMALL',
+      ],
+      'configurations': {
+        'Common_Base': {
+          'msvs_target_platform': 'x64',
+        },
+      },
+      # TODO(davidben): Fix size_t truncations in BoringSSL.
+      # https://crbug.com/429039
+      'msvs_disabled_warnings': [ 4267, ],
+      'conditions': [
+        ['component == "shared_library"', {
+          'defines': [
+            'BORINGSSL_SHARED_LIBRARY',
+          ],
+        }],
+      ],
+      'include_dirs': [
+        'src/include',
+      ],
+      'direct_dependent_settings': {
+        'include_dirs': [
+          'src/include',
+        ],
+        'conditions': [
+          ['component == "shared_library"', {
+            'defines': [
+              'BORINGSSL_SHARED_LIBRARY',
+            ],
+          }],
+        ],
+      },
+    },
+    {
       'target_name': 'boringssl',
       'type': '<(component)',
       'sources': [