Created an empty expectations file to ignore flaky tests

tools/ignorer_bot/ignored_failed_tests.txt

+# This file contains a list of ignored failed tests. Each line that starts with
+# a hash (#) or empty is ignored. Other lines are parsed by the test runner to
+# ignore failures of specified tests on particular platforms. Each such line has
+# the following format:
+#
+#   http://crbug.com/ISSUE [ PLATFORM1, PLATFORM2, ... ] TESTNAME

[eseidel, 2014/07/08 19:51:59]

Are you sure you want commas in this list?

[Sergiy Byelozyorov, 2014/07/09 13:30:19]

Yes, how otherwise should I separate platform definitions? For example a
definition with 3 platforms will look as following:

http://crbug.com/12345 [ OS_LINUX CPU_64_BITS MODE_RELEASE, OS_LINUX CPU_32_BITS
MODE_DEBUG,
OS_WIN CPU_32_BITS MODE_RELEASE ] MyTests.TestOne

Spaces are used to split flags within a since platform definition, while commas
are used to split platforms.

[ojan, 2014/07/09 17:34:02]

Can we use exactly the same format as third_party/WebKit/LayoutTests/FlakyTests?
We should use the same code to parse the files and it's less overhead for
developers to need to understand only format.

Here's the list of things I see that are different
-No http:// before the bug numbers.
-Include the failure type at the end [ Failure ]. Right now that's the only mode
for gtests, but in the future we'll want to distinguish timeouts and crashes
like we do for blink tests.
-Use the same plaform identifiers: s/OS_Linux/Linux, s/MODE_RELEASE/Release.
-No 32 bit vs. 64 bit identifiers. We used to have this in Blink and it was used
so rarely that it wasn't worth the confusion. It's really rare to have tests
that are flaky only on one of 32 bit or 64 bit. We can add this back in the
future if we find a need for it, but lets start with leaving it out.

[Sergiy Byelozyorov, 2014/07/10 11:12:56]

Done.
Right now this is not the only type. We ignore flaky tests which fail on any
types. I can add this, but it will be for now ignored by the test runner, which
ignores any failures of the test in the list.
This will require writing and supporting a hard-coded mapping from flags to
platforms. In particular this mapping will have to be updated each time the new
platforms are added. Why not use flags directly?
Why would this be confusing? Developers will hardly ever read this file and if
the test is flaky on both 32-bit and 64-bit platforms both will be added
automatically.

+#
+# where
+#  - ISSUE is the id of the associated issue for the flaky test;
+#  - PLATFORM1, PLATFORM2 etc. are each formated as a list of platform flags
+#    separated by whitespace, e.g. "OS_WIN CPU_32_BITS MODE_RELEASE" and limit
+#    on which platforms the test is disabled (note that square brackets and
+#    commas are part of the syntax and do NOT denote this section as optional);
+#  - TESTNAME is a name of the test to be ignored.
+#
+# This file is edited automatically by the ignorer-bot tool, which automatically
+# ignores highly flaky tests. However, it may also be edited manually as long as

[ojan, 2014/07/09 17:34:02]

I think we should keep this file 100% auto-generated. No manual changes. That
way we can freely remove things when they stop being flaky. If people manually
add lines, we won't know what we can remove and what we can't.

[Sergiy Byelozyorov, 2014/07/10 11:12:56]

In the first version we will not remove tests automatically and people will need
to edit this file to restore them manually.

+# format spec is followed.