Add testing configs for ParseHTMLOnMainThread experiment

testing/variations/fieldtrial_testing_config_linux.json

 {
     "AsyncDNS": [
         {
             "group_name": "AsyncDNSA"
         }
     ],
     "AutofillClassifier": [
         {
             "group_name": "Enabled"
         }
@@ skipping 137 matching lines @@
     "OutOfProcessPac": [
         {
             "group_name": "Enabled"
         }
     ],
     "PageRevisitInstrumentation": [
         {
             "group_name": "Enabled"
         }
     ],
+    "ParseHTMLOnMainThread": [
+        {
+            "enable_features": [
+                "ParseHTMLOnMainThread"
+            ],
+            "group_name": "Enabled_SyncTokenize",
+            "params": {
+                "parseHTMLOnMainThreadCoalesceChunks": "false",
+                "parseHTMLOnMainThreadSyncTokenize": "true"
+            }

[Ilya Sherman, 2016/08/10 05:53:13]

I think the best practice is to test the configuration that you are most likely
to ship, and to test that configuration on each platform, rather than testing
one configuration per platform.  This allows us to catch, e.g. performance
regressions, even if they happen only on a single platform.

[Charlie Harrison, 2016/08/10 12:05:31]

That makes sense, but I'd argue that shipping experiment groups that are not
tested (or tested on a small subset of tests) is worse than missing platform
specific behavior of an experiment group.

In this case I think we can reach a compromise, as most of the code this touches
is tested by layout tests which can have virtual test suites added. However as
discovered by this CL this doesn't catch everything :)

WDYT?

[Ilya Sherman, 2016/08/10 18:53:21]

In general, each feature's tests should test all the configurations for that
feature.  These config files are for running the *entire* test suite with the
most likely field trial configuration for shipping, to see if there are any
unexpected regressions detected by more general tests.  Thus, we prefer to test
a single configuration, the one that is actually going to be launched to users
assuming that nothing looks wrong.  We only require/recommend adding these
configs once the field trial is reaching the Beta channel, on the assumption
that by that point, it's usually pretty clear which configuration is the most
promising one.

Now, there's a lot of assumptions in the above, which aren't necessarily correct
-- most notably, that there's enough data prior to testing on Beta to determine
which configuration is most promising.  For this particular experiment, which
configuration are you *expecting* to ship?  Is there a single candidate, or
multiple ones?

+        }
+    ],
     "PasswordBranding": [
         {
             "group_name": "SmartLockBrandingSavePromptOnly"
         }
     ],
     "PasswordManagerSettingsMigration": [
         {
             "group_name": "Enable"
         }
     ],
@@ skipping 223 matching lines @@
     ],
     "use-new-media-cache": [
         {
             "enable_features": [
                 "use-new-media-cache"
             ],
             "group_name": "Enabled"
         }
     ]
 }