Non-SFI mode: Quick workaround of unexpected CHECK failure.

Recently, crrev.com/418423002 is landed, but it has a bug in Non-SFI mode.
It introduces CHECK for the file token in ManifestService::OpenResource().
However, in Non-SFI mode, there is no NaClIPCAdapter, so the token is passed
from the renderer directly. (Actually the IPC channel is connected directly
to the renderer).
As a result, if the renderer fills the file token properly, it crashes.
As far as I investigated, it happens, at least, when the fast-path is triggered
(i.e. OpenNaClExecutable works in DownloadFile in ppb_nacl_private_impl.cc).
Anyway, we can ignore file tokens in Non-SFI mode, because it is for
SFI NaCl's validation cache.

BUG=394130
TEST=Ran trybots. Patched locally and run our Non-SFI NaCl app.
CQ_EXTRA_TRYBOTS=tryserver.chromium.linux:linux_rel_precise32

Review URL: https://codereview.chromium.org/560983003

Cr-Commit-Position: refs/heads/master@{#294396}

ppapi/nacl_irt/manifest_service.cc

@@ -104,10 +104,16 @@ bool ManifestService::OpenResource(const char* file, int* fd) {
     return false;
   }
 
+#if defined(OS_NACL)
   // File tokens are used internally by NaClIPCAdapter and should have
   // been cleared from the message when it is received here.
+  // Note that, on Non-SFI NaCl, the IPC channel is directly connected to the
+  // renderer process, so NaClIPCAdapter does not work. It means,
+  // file_token_{lo,hi} fields may be properly filled, although it is just
+  // ignored here.
   CHECK(file_token_lo == 0);
   CHECK(file_token_hi == 0);
+#endif
 
   // Copy the file if we received a valid file descriptor. Otherwise, if we got
   // a reply, the file doesn't exist, so provide an fd of -1.