Best way to trigger (parts of?) content initialization in app shim processes

[Marijn Kruisselbrink]

In https://chromium-review.googlesource.com/c/chromium/src/+/7398643 I'm trying to fix an issue where in some cases an AppShim (helper process for installed Web Apps on macOS; content doesn't and shouldn't really need to know anything specific about this process type) will end up terminating itself because it receives a mojo message containing an origin with an unknown scheme. AppShim processes aren't regular child processes and as such currently don't invoke ContentMain (or much of the rest of content initialization), and as a result of that content::RegisterContentSchemes isn't called either and thus content schemes aren't registered.

This can be fixed fairly easily by adding a call to RegisterContentSchemes somewhere in early app shim startup code, as that CL does, but that requires adding RegisterContentSchemes to the public content API even though in any other case embedders would have no reason to call this method as ContentMain already does so.

Since ContentMain apparently is the public entry point to (among many other things) RegisterContentSchemes, perhaps app shims should be refactored to go through there as well? I'm not sure what all else ContentMain does (and at least some of what it does would need to be skipped/disabled since app shims need to do it slightly different), but that approach does seem to work (prototyped in https://chromium-review.googlesource.com/c/chromium/src/+/7402162, which with some minor additions to ContentMainDelegate seemingly is at least passing all our tests).

But I'm not sure what the best approach is here to address this:

- exposing and calling RegisterContentSchemes is a simple and targetted fix, and doesn't really have any risk of having unexpected side effects in app shims. But the resulting content/public API isn't great

- switching app shims to start calling ContentMain is perhaps a better long term solution, but at least I don't fully understand the consequences of that, as ContentMain seemingly does a lot of things, that might or might not all apply to app shims (and does those things before for example app shims have fully initialized base::FeatureList). As such this approach feels more risky, although it seems to work.

Any thoughts/opinions/other options I haven't thought about?