[wip] Add some more state to RenderViewHost's lifetime.

[wip] Add some more state to RenderViewHost's lifetime.

Keep track of in-flight copy-requests for a RenderViewHost. If a RenderViewHost
has pending copy-requests, then:
  * Do not decrement active-view-count on the SiteInstance when the
    RenderViewHost becomes inactive.
  * Hold back sending was-swapped-out IPC to the renderer.
  * Do not run the shutdown-on-swap callback.

When all the copy-requests are completed in the RenderViewHost:
  * Check if the current state of the RenderViewHost is not active anymore.
    If it's not active, then send the was-swapped-out message. This should
    work because new copy-requests are not made if the RenderViewHost isn't
    in an active state.
  * If the current state is not active, then also decrement the active-view
    count on the SiteInstance.
  * If the state is in a pending-shutdown state, then run the callback.

BUG=340682

[sadrul, 2014-02-25 15:47:57]

Hi! This is an alternate approach to keep a swapped-out RenderViewHost alive for
long enough for its screenshot to be captured successfully. A previous attempt
was here: https://codereview.chromium.org/166533002/

Unlike the previous attempt, this change doesn't [seem to] break any of the
existing tests. Does this look like a reasonable approach? I have tried to
explain the change in the CL description in detail, but I can put this up in an
informal design doc if you think that'd be better for discussion.

PS: this depends on clamy@'s r249676 (which is currently reverted to investigate
crbug.com/345757)

Thanks!

[Charlie Reis, 2014-02-25 17:35:43]

I like that this is much simpler.  I haven't looked closely yet, but I wanted to
point out that we're investigating some serious leaks related to RenderViewHost
in http://crbug.com/343002 in addition to http://crbug.com/345757.  We'll
probably want to solve those first to understand the problem.  (I'm bogged down
with those at the moment anyway, so I'll try to review this once we have an
answer.)

[clamy, 2014-02-26 16:50:56]

The approach seems good, but I am concerned about the modifications in the
reference count of SiteInstance.
Please also note that I am working on a reland of the patch for the background
unload event, that has a fix for a related problem in the logic of WasSwappedOut
(https://chromiumcodereview.appspot.com/180993003/).

https://chromiumcodereview.appspot.com/178843004/diff/1/content/browser/rende...
File content/browser/renderer_host/render_view_host_impl.cc (right):

https://chromiumcodereview.appspot.com/178843004/diff/1/content/browser/rende...
content/browser/renderer_host/render_view_host_impl.cc:2093: copy_requests_ ==
0)
If the site instance is not decremented when the new page commits (ie when
WasSwappedOut is called), then the RVH will not go into state PENDING_SHUTDOWN.
Its associated RFH will be stored in the map of swapped out hosts in the
RenderFrameHostManager. When the swap out ack is received, the state will just
be set to SWAPPED_OUT, and the RFH and RVH will not be deleted as they should
be.

[mfomitchev, 2014-03-24 18:49:09]

https://chromiumcodereview.appspot.com/178843004/diff/1/content/browser/rende...
File content/browser/renderer_host/render_view_host_impl.cc (right):

https://chromiumcodereview.appspot.com/178843004/diff/1/content/browser/rende...
content/browser/renderer_host/render_view_host_impl.cc:1880:
pending_shutdown_on_swap_out_.Run();
Can't we have a situation where this gets executed before
RenderViewHostImpl::OnSwappedOut()? If that happens,
pending_shutdown_on_swap_out_ will be executed twice..