Attempt to de-flake PartitionAllocTest.ZeroFill on small devices.

The test allocates a random but potentially very large amount of memory, and in
some cases that can cause flaking (OOM, timeouts). This CL reduces the number of
random-size allocations, putting a lower ceiling on the memory use. Let's see if
that's enough to de-flake the test while still keeping it sufficiently
stressful. If necessary, we could possibly reduce the ceiling further, but let's
start here.

Bug: 966169
Change-Id: If5e632271f0c4b7117a666e96bf1873c233f5958
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1635355Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Chris Palmer <palmer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#664559}

base/allocator/partition_allocator/partition_alloc_unittest.cc

@@ -2184,14 +2184,7 @@ TEST_F(PartitionAllocTest, SmallReallocDoesNotMoveTrailingCookie) {
   generic_allocator.root()->Free(ptr);
 }
 
-// TODO(crbug.com/966169): This test is flaky on Fuchsia.
-#if defined(OS_FUCHSIA)
-#define MAYBE_ZeroFill DISABLED_ZeroFill
-#else
-#define MAYBE_ZeroFill ZeroFill
-#endif  // defined(OS_FUCHSIA)
-
-TEST_F(PartitionAllocTest, MAYBE_ZeroFill) {
+TEST_F(PartitionAllocTest, ZeroFill) {
   constexpr static size_t kAllZerosSentinel =
       std::numeric_limits<size_t>::max();
   for (size_t size : kTestSizes) {
@@ -2211,7 +2204,7 @@ TEST_F(PartitionAllocTest, MAYBE_ZeroFill) {
 
   for (int i = 0; i < 10; ++i) {
     SCOPED_TRACE(i);
-    AllocateRandomly(generic_allocator.root(), 1000, PartitionAllocZeroFill);
+    AllocateRandomly(generic_allocator.root(), 250, PartitionAllocZeroFill);
   }
 }