Headless tests: Update navigation tracking to avoid a race condition.

Why there is a the race condition:
==================================

Given this document:
~~~
<html>
  <head>
    <script>
      document.location = 'http://www.example.com'
    </script>
  </head>
  <body>
    [...]
  </body>
</html>
~~~

The scheduled navigation to http://www.example.com may starts before the
document has finish loading. It depends on the size of the document and
how things are scheduled in blink.

FrameLoader::StartLoad() executes: ProgressTracker::ProgressStarted()
which executes probe::frameStartedLoading() if and only if the frame is
not loading currently.

Since it can be called or not, it causes the HeadlessRenderTest to drop
some navigations and a test to fail.

I am working on https://crbug.com/831155. It makes some navigations to
start sooner. This test is failing:
HeadlessRenderBrowserTestClientRedirectChain.RunAsyncTest
This CL keeps it working.

Description of the patch:
=========================

Using:
 1) frameScheduledNavigation
 2) frameStartedLoading
 3) frameClearScheduledNavigation
is not a correct way to track navigation. A new navigation can start
before the previous one has finished loading. So the second
frameStartedLoading may or may not be sent.

This patch makes tests to continue to track whether or not some
navigation have been scheduled using 1), but it stops trying to get
informations from 2) and 3).

More generally, I think using frameScheduledNavigation and
frameClearScheduledNavigation should be avoided. At a first sight, I
think it will miss some navigations, at least every browser initiated
ones and maybe some renderer initiated too.

Bug: 831155
Change-Id: I3bd18a6b20ee5a73e0116244066ee699822dec33
Reviewed-on: https://chromium-review.googlesource.com/1071630
Reviewed-by: Alex Clarke <alexclarke@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#562241}
3 files changed