Bug 1655278 - Stop forcing a composite when we have fallen 2 vsync intervals behind. r=kats

Currently on Android when CompositorVsyncScheduler detects that we requested a
composite more than 2 vsync intervals ago it forces an immediate composite. This
is a relic from times when vsync observation occured on the main thread, and
Fennec was single-process. (The logic being that if the main thread was busy and
it would be better to composite immediately rather than wait for the vsync
notification.)

Neither of these conditions are true nowadays, and geckoview should be no worse
than desktop platforms in this regard, so let's remove this code.

Depends on D85611

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

gfx/layers/ipc/CompositorVsyncScheduler.cpp

@@ -147,18 +147,6 @@ void CompositorVsyncScheduler::ScheduleComposition() {
     // Used only for performance testing purposes, and when recording/replaying
     // to ensure that graphics are up to date.
     PostCompositeTask(vsyncEvent);
-#ifdef MOZ_WIDGET_ANDROID
-  } else if (mIsObservingVsync && mCompositeRequestedAt &&
-             (TimeStamp::Now() - mCompositeRequestedAt) >=
-                 mVsyncSchedulerOwner->GetVsyncInterval() * 2) {
-    // uh-oh, we already requested a composite at least two vsyncs ago, and a
-    // composite hasn't happened yet. It is possible that the vsync observation
-    // is blocked on the main thread, so let's just composite ASAP and not
-    // wait for the vsync. Note that this should only ever happen on Fennec
-    // because there content runs in the same process as the compositor, and so
-    // content can actually block the main thread in this process.
-    PostCompositeTask(vsyncEvent);
-#endif
   } else {
     if (!mCompositeRequestedAt) {
       mCompositeRequestedAt = TimeStamp::Now();