Speed up flaky test DontIgnoreBackAfterNavEntryLimit.

This test is slow on debug builds in general but on Mac and Win it's
slow enough to cause timeout flakes.

FIX: Set the entry-count limit to 10. This test takes 15s on my desktop
before this change and 6 afterwards, so the build bots should be OK.

Bug: 1167300
Change-Id: Iaf3cf63aed26dc0a79a02cb6b2af6ecada30303f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2636633Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Fergal Daly <fergal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#844669}

content/browser/renderer_host/navigation_controller_impl_browsertest.cc

@@ -1078,17 +1078,14 @@ IN_PROC_BROWSER_TEST_P(NavigationControllerBrowserTest, UniqueIDsOnFrames) {
 // interfere with navigations. We switched to a different scheme, so now this is
 // just a test to make sure we can still navigate once we prune the history
 // list.
-// Test is flaky on Win and debug builds.
-#if defined(OS_WIN) || !defined(NDEBUG)
-#define MAYBE_DontIgnoreBackAfterNavEntryLimit \
-  DISABLED_DontIgnoreBackAfterNavEntryLimit
-#else
-#define MAYBE_DontIgnoreBackAfterNavEntryLimit DontIgnoreBackAfterNavEntryLimit
-#endif
 IN_PROC_BROWSER_TEST_P(NavigationControllerBrowserTest,
-                       MAYBE_DontIgnoreBackAfterNavEntryLimit) {
+                       DontIgnoreBackAfterNavEntryLimit) {
   NavigationController& controller = shell()->web_contents()->GetController();
 
+  // The default (50) makes this test too slow and leads to flakes
+  // (https://crbug.com/1167300).
+  NavigationControllerImpl::set_max_entry_count_for_testing(10);
+
   const int kMaxEntryCount =
       static_cast<int>(NavigationControllerImpl::max_entry_count());