Don't exercise legacy path for known roots on modern NSS

NSS 3.30 introduced PK11_HasAttributeSet, which allows callers
to query the PKCS#11 tokens for given PKCS#11 attributes. The
same release also added attributes to the default NSS trust
store indicating they were part of the default store - i.e.
they were not added by admins.

Prior to NSS 3.30, the only way for determining 'default'
trust was to query the token and slot name, as nssckbi.so,
the read-only default trust store. Unfortunately, other
libraries, such as p11-kit-trust, decided to emulate that, but
also included administrative and user-added roots in the store,
resulting in user-added roots being subjected to public trust
requirements.

While the issue is in p11-kit-trust not observing the
semantics that NSS relied on (e.g. by adding themselves as a
separate token/slot, or preserving the 'default-only' nature
of the .so), work around this by adding a short-circuit when
the PK11_HasAttributeSet symbol is resolved.

This short-circuit can be reasoned about as safe, as the other
change in M68 - to use GetNetTrustAnchorHistogramForSPKI -
ensures that publicly trusted roots are recognized as such. This
path only handles the "old Chrome, new trust store" scenario,
which is quite rare.

Bug: 868811
Change-Id: I21989ee3e0c59dd9bfd199a6b13334637f0772c5
Reviewed-on: https://chromium-review.googlesource.com/1167479Reviewed-by: Eric Roman <eroman@chromium.org>
Commit-Queue: Ryan Sleevi <rsleevi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581665}

net/cert/known_roots_nss.cc

@@ -84,6 +84,8 @@ bool IsKnownRoot(CERTCertificate* root) {
         }
       }
     }
+
+    return false;
   }
 
   // This magic name is taken from