Now that we've shipped --isolate-extensions, AreCrossProcessFramesPossible returns true on all platforms except for Android, where it's still gated on one of our other OOPIF modes being enabled.  We should try to enable it on Android and then rip it out altogether, as it's complicating feature work for sign-in isolation and safe browsing (see https://codereview.chromium.org/2831683002/diff/80001/content/common/site_isolation_policy.cc#newcode22), and possibly leading to bugs on Android if we inadvertently start relying on the AreCrossProcessFramesPossible paths (e.g., DidNavigateFrame being called for all subframes from DidNavigate --
 see https://codereview.chromium.org/2883213002/#msg11).

The main uses of AreCrossProcessFramesPossible are currently:
1. Enable the event router in the browser process.
2. Skip certain proxy creation and replication work when OOPIFs are off.
3. Skip calling RFHM::DidNavigateFrame for subframes if OOPIFs are off.
4. Some sanity CHECKs to verify that certain things can only happen when OOPIFs are possible.
5. Decide whether to checks for transfers with IsRendererTransferNeededForNavigation in NavigationHandleImpl::MaybeTransferAndProceedInternal.
6. Some other shortcuts in process model decisions, such as in ShouldTransitionCrossSite and CanSubframeSwapProcess.

One blocker we're currently aware of is the perf regression in  issue 690229 .  Android hit testing used to be another blocker, but kenrb@ has since fixed that in r455559. We should investigate/fix  issue 690229  and then clean up the checks above to just assume that OOPIFs are always possible.