Add --site-per-process flavor of //content tests to Site Isolation Android bot.

testing/buildbot/chromium.fyi.json

 {
   "Android Asan Builder Tests (dbg)": {
     "gtest_tests": [
       {
         "args": [
           "--tool=asan"
         ],
         "swarming": {
           "can_use_on_swarming_builders": false
         },
@@ skipping 11371 matching lines @@
             {
               "android_devices": "4",
               "device_type": "bullhead"
             }
           ],
           "hard_timeout": 960
         },
         "test": "content_browsertests"
       },
       {
+        "args": [
+          "--gtest-filter-file=../../testing/buildbot/filters/site-per-process.content_browsertests.filter",

[alexmos, 2016/10/18 23:36:10]

Will this be properly picked up by swarming?  Looking at content/test/BUILD.gn,
I see this:
     if (is_win || is_linux) {
        data += [
"//testing/buildbot/filters/site-per-process.content_browsertests.filter" ]
      }

This seems like it needs an is_android check as well now.

[Łukasz Anforowicz, 2016/10/19 00:06:39]

Thanks for pointing this out.  Done.  For a moment I wondered whether to simply
pull in the filter file on all architectures, but then I decided to just add
|is_android|, because we seem to be really granular with other things in this
BUILD.gn file.

+          "--test-arguments=--site-per-process"
+        ],
+        "name": "site_per_process_content_browsertests",

[alexmos, 2016/10/18 23:36:10]

Why do we want to run the same sets of tests with and without
--site-per-process?  Is it to distinguish from the set of tests that have been
flaky on this bot even without --site-per-process?

[Łukasz Anforowicz, 2016/10/19 00:06:39]

Yes - exactly.  I'd like to do this for a while, especially given that we've
seen the bot getting red from time to time without --site-per-process.  We can
reevaluate if this impacts the runtimes too much.

Also - this way things are similar to how linux tests are setup on the CQ
(including the step names like "site_per_process_content_browsertests").

+        "override_isolate_target": "content_browsertests",
+        "swarming": {
+          "can_use_on_swarming_builders": true,
+          "dimension_sets": [
+            {
+              "android_devices": "4",
+              "device_type": "bullhead"
+            }
+          ],
+          "hard_timeout": 960
+        },
+        "test": "content_browsertests"
+      },
+      {
         "override_isolate_target": "content_unittests",
         "swarming": {
           "can_use_on_swarming_builders": true,
+          "dimension_sets": [
+            {
+              "android_devices": "4",
+              "device_type": "bullhead"
+            }
+          ]
+        },
+        "test": "content_unittests"
+      },
+      {
+        "args": [
+          "--test-arguments=--site-per-process"

[alexmos, 2016/10/18 23:36:10]

Glad we don't have a filter file for unit tests, and fingers crossed that
Android won't break any additional ones. :)

[Łukasz Anforowicz, 2016/10/19 00:06:39]

Yes.  I was wondering whether to include an Android-specific filter file (at
least for content_browsertests) in the CL under review...  I think - let's see
first if there are any Android-specific failures and maybe we'll get lucky (and
maybe what I saw in https://crbug.com/654569#c4 was just transient failures or
failures specific to my local test environment).

+        ],
+        "name": "site_per_process_content_unittests",
+        "override_isolate_target": "content_unittests",
+        "swarming": {
+          "can_use_on_swarming_builders": true,
           "dimension_sets": [
             {
               "android_devices": "4",
               "device_type": "bullhead"
             }
           ]
         },
         "test": "content_unittests"
       }
     ]
@@ skipping 1173 matching lines @@
       },
       {
         "swarming": {
           "can_use_on_swarming_builders": true
         },
         "test": "views_unittests"
       }
     ]
   }
 }