IsStringUTF8 and StreamingUtf8Validator can differ.

This is relatively harmless, but can hit a NOTREACHED. This change makes
the CTAP2 parsers follow the stricter, IsStringUTF8, result.

Bug: 955317
Change-Id: If7f8b8a0c1e85566bb035b21626d52fd91038a42
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1576337
Commit-Queue: Adam Langley <agl@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Auto-Submit: Adam Langley <agl@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#653214}

device/fido/device_response_converter.cc

@@ -339,11 +339,11 @@ static base::Optional<std::string> FixInvalidUTF8String(
 
   switch (state) {
     case base::StreamingUtf8Validator::VALID_ENDPOINT:
-      // This shouldn't happen because this callback should only be called
-      // when the UTF-8 was found to be invalid. Thus reaching this point
-      // suggests a divergence between |StreamingUtf8Validator| and
-      // |base::IsStringUTF8|, which the CBOR code uses.
-      NOTREACHED();
+      // |base::IsStringUTF8|, which the CBOR code uses, is stricter than
+      // |StreamingUtf8Validator| in that the former rejects ranges of code
+      // points that should never appear. Therefore, if this case occurs, the
+      // string is structurally valid as UTF-8, but includes invalid code points
+      // and thus we reject it.
       return base::nullopt;
 
     case base::StreamingUtf8Validator::INVALID: