Convert utility process extension ParseUpdate IPC to mojo

extensions/common/manifest_parser.typemap

Index: extensions/common/manifest_parser.typemap
diff --git a/extensions/common/manifest_parser.typemap b/extensions/common/manifest_parser.typemap
new file mode 100644
index 0000000000000000000000000000000000000000..82cb2b06ec1ba8608b83bd55e6704ada0c644adf
--- /dev/null
+++ b/extensions/common/manifest_parser.typemap
@@ -0,0 +1,18 @@
+# Copyright 2017 The Chromium Authors. All rights reserved.
+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+mojom = "//extensions/common/manifest_parser.mojom"
+
+public_headers = [ "//extensions/common/update_manifest.h" ]
+
+traits_headers = [ "//extensions/common/manifest_parser_struct_traits.h" ]
+
+sources = [
+  "//extensions/common/manifest_parser_struct_traits.cc",
+]
+
+type_mappings = [
+  "extensions.mojom.UpdateManifestResults=::UpdateManifest::Results",

[Devlin, 2017/03/21 23:51:16]

I wonder if it would make sense to just use the mojo types instead of
UpdateManifest::Results?  It would save on conversion/copies, and they're just
data structs... maybe add a TODO somewhere? (In UpdateManifest?)

[Noel Gordon, 2017/03/22 01:34:50]

You might recall the recent enum Manifest::location change we did.  We did think
about re-writing callers in terms of the mojo enum type (didn't mention it as
option in review), but there were many call-sites in extensions that would'a
needed updating to do that (too many for that particular patch set).

But "just use the mojo types instead" is always good thing to consider, given
...
and, furthermore, saves you having to decide upon using [Native] traits, or else
building mojo struct traits, etc, etc.  So indeed, lots of benefits and,
assuming callers / call-sites can be easily updated to use the mojo type(s),
it's a good way to go ...
... or consider: TODO done.

+  "extensions.mojom.UpdateManifestResult=::UpdateManifest::Result",
+]