Move Blink Sandbox IPC to Mojo Calls

This is a reland of
https://chromium-review.googlesource.com/c/chromium/src/+/1109964
Tbr'ing previous reviewers from that CL as the exact change has been
previously reviewed there.

The revert was done manually in response to flakiness of viz_browser
tests in MSAN. See issue https://crbug.com/860349 - my analysis is in
issue https://crbug.com/860445 where I disable this test. In short, I
believe my CL exposed a previously existing race condition in that test.

Instead of Chromium IPC macro-defined messages or Mojo, Chrome on Linux
uses hand-pickled IPC messages through a special purpose file descriptor
to send messages from the renderer to the browser host in order to
access FontConfig for font matching and font fallback. This system is
described in docs/linux_sandbox_ipc.md.

For the "Font Matching by Full Font Name / PS Name" effort, see issue
828317, additional out of process font methods are needed. Instead of
adding them to this legacy hand-written IPC, we modernize the Linux
Sandbox IPC mechanism and upgrade it to using Mojo interface definitions
and a service architecture, in which a font service running in an
unsandboxed utility process answers FontConfig requests from the
renderer.

Previous CLs [1], [2] prepared the Font Service to have testing and
additional font fallback and render-style-for-strike methods. Now we can
move Blink over to using this Mojo interface and remove the traditional
sandbox IPC handlers since we do not use the file descriptor based IPC
anymore for FontConfig acces.

For more details, please refer to the design doc in issue 839344.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/1091754
[2] https://chromium-review.googlesource.com/c/chromium/src/+/1087951

Bug: 855021
Change-Id: I74663c5685a7797089e4d69354453146c245e20a
Tbr: skyostil@chromium.org, michaelpg@chromium.org, rsesek@chromium.org, halliwell@chromium.org, thestig@chromium.org, piman@chromium.org, eae@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/1127028
Commit-Queue: Dominik Röttsches <drott@chromium.org>
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Cr-Commit-Position: refs/heads/master@{#572930}

docs/linux_sandbox_ipc.md

@@ -4,11 +4,13 @@ The Sandbox IPC system is separate from the 'main' IPC system. The sandbox IPC
 is a lower level system which deals with cases where we need to route requests
 from the bottom of the call stack up into the browser.
 
-The motivating example is Skia, which uses fontconfig to load fonts. In a
-chrooted renderer we cannot access the user's fontcache, nor the font files
-themselves. However, font loading happens when we have called through WebKit,
-through Skia and into the SkFontHost. At this point, we cannot loop back around
-to use the main IPC system.
+The motivating example used to be Skia, which uses fontconfig to load
+fonts. Howvever, the OOP IPC for FontConfig was moved to using Font Service and
+the `components/services/font/public/cpp/font_loader.h` interface.
+
+These days, only the out-of-process localtime implementation as well as
+an OOP call for making a shared memory segment are using the Sandbox IPC
+file-descriptor based system. See `sandbox/linux/services/libc_interceptor.cc`.
 
 Thus we define a small IPC system which doesn't depend on anything but `base`
 and which can make synchronous requests to the browser process.
@@ -36,22 +38,12 @@ requests so that should be a good starting point.
 
 Here is a (possibly incomplete) list of endpoints in the renderer:
 
-### fontconfig
+### localtime
 
-As mentioned above, the motivating example of this is dealing with fontconfig
-from a chrooted renderer. We implement our own Skia FontHost, outside of the
-Skia tree, in `skia/ext/SkFontHost_fontconfig**`.
+`content/browser/sandbox_ipc_linux.h` defines HandleLocalTime which is
+implemented in `sandbox/linux/services/libc_interceptor.cc`.
 
-There are two methods used. One for performing a match against the fontconfig
-data and one to return a file descriptor to a font file resulting from one of
-those matches. The only wrinkle is that fontconfig is a single-threaded library
-and it's already used in the browser by GTK itself.
+### Creating a shared memory segment
 
-Thus, we have a couple of options:
-
-1.  Handle the requests on the UI thread in the browser.
-1.  Handle the requests in a separate address space.
-
-The original implementation did the former (handle on UI thread). This turned
-out to be a terrible idea, performance wise, so we now handle the requests on a
-dedicated process.
+`content/browser/sandbox_ipc_linux.h` defines HandleMakeSharedMemorySegment
+which is implemented in `content/browser/sandbox_ipc_linux.cc`.