Bug 1496380 - stop recursion via the external protocol handler if Firefox is...

Bug 1496380 - stop recursion via the external protocol handler if Firefox is either the default OS handler or a configured external handler, r=mossop

This is an initial implementation of this idea that works on mac.
I've added a Windows implementation in another commit in this stack. I'll
look at a Linux one in a follow-up bug. I do not think we need them in the
child process implementation or on Android.

Effectively, this makes nsIHandlerInfo::LaunchWithURI() fall back to asking if
the handler info points to the OS default and that's us, or if it points to
a helper app and that's us. The latter is fairly easy to check, but the former,
more common case, is actually annoying - there don't seem to be APIs on the
external helper app service or the handler service that provide any information
about the app that's currently the default. So despite my belief that these
interfaces have too many methods that all do very similar things, and what we
need is fewer interfaces with fewer methods, I added another one...

For this mac implementation, I'm comparing bundle URLs and added newer API
usage for 10.10 and later to avoid deprecation warnings. I've not changed
the mac shell service as it uses bundle identifiers to check if we're the
default.

Another way of fixing these issues would be to complain about things when we
receive these URIs from external parties and our own config says that we will
just hand them to someone else. I decided not to do so because we end up with
at least one of the following problems:

- if we implement in BrowserContentHandler, that won't help for
  PWAs/Thunderbird
- if we try to implement in the external protocol handler, we'd need to start
  passing load flag information through to lots of checks.
- it wouldn't stop the recursion until we've already done one round of
  it for links that are in webpages, which seems suboptimal (ie, if you
  clicked a mailto: link on a webpage it'd go to the OS with that mailto link
  and only realize something's awry when we've gone back through the OS to us,
  rather than straightaway).

If we wanted to, we could add a fix like that in belt-and-suspenders fashion.

Differential Revision: https://phabricator.services.mozilla.com/D48742

--HG--
extra : moz-landing-system : lando