Mac ÜC: Fix white page hangs

Mac ÜC: Fix white page hangs

The root cause of the white page hangs is that messages sent to a
RenderWidgetHelper (as was added in r281866 to enable smooth resize),
the message could be dropped if the RenderWidgetHelper was destroyed.
This is a valid behavior for messages that are specifically for a given
renderer process, but it is not a valid behavior for browser compositor
swaps (because we use these messages to throttle the compositor, and
will hang if they never arrive).

To fix this, always post a task to handle
ViewHostMsg_CompositorSurfaceBuffersSwapped messages, in addition
to forwarding the message to the RenderWidgetHelper. Add a unique
token to each ViewHostMsg_CompositorSurfaceBuffersSwapped and track
which tokens are outstanding, to ensure that each message is only sent
once. This is a somewhat bulky way of solving the problem, because
the RenderWidgetHost does its filtering during resize through IPCs, which
can't have pointers to unique data structures in them. A bug on doing
something more sensible is already open.

While in the neighborhood, make the behavior of client-less swaps more
explicit -- un-block the renderer, but do not draw them. The situation
where a swap for a removed client arrived was somewhat dangerous, in
that it may be that the efforts to draw the frame would fail, resulting in
a failure to ack the frame, and a hang.

Also while in the neighborhood, replace the setNeedsDisplay+displayIfNeeded
call with a immediatelyForceDisplayAndAck, because it has been shown
that displayIfNeeded can sometimes do nothing (in which case we might
never ack).

BUG=392760

[ccameron, 2014-07-11 12:04:38]

This is a hack on top of a hack. I can't wait to get RenderWidgetHelper's IPC
filtering scheme on the operating table.

I'm now fairly certain that this issue is r281866, not enabling delegated
rendering. If this looks reasonable enough and can make Friday's Canary, that's
great -- otherwise, I'll revert r281866, but leave delegated rendering enabled.

[danakj, 2014-07-11 15:37:12]

After all the discussion we've had about the synchronous composite, I'm inclined
to suggest reverting r281866.

1) Doing a sync draw in the browser just to ack faster to unblock the renderer
from producing frames is a giant hammer when all we really want to do is unblock
the renderer and allow it to produce another frame. This is a scheduling problem
in the renderer, not in the browser.
2) It's causing headache for enne@ to land the CL to get the browser comp using
the scheduler.

These two things together suggest maybe we should back up and rethink how to
solve that problem correctly. My 2 cents.