Rework the way we find old builds in garden-o-matic.

When I converted garden-o-matic to look in cloud storage for build results,
I had to use the cloud storage APIs for directory listings, which are very
primitive; they only let you do lexicographically sorted listings across
the every file in the bucket, e.g., 'WebKit_Linux/1100/failing_results.json'.

So, we would take the most recent build, subtract a hundred, and then list
the files starting at that index. Cloud Storage would return some of the
listings and a 'nextMarker' to indicate where to start on the next query.
So, we might start at 'WebKit_Linux/1000/', for example, and get back a
the results up until 'WebKit_Linux/1097/' and a marker of 'WebKit_Linux/1098/'.
Unfortunately, we would then fetch the next set of results, which would
continue on the to the next items found lexicographically (e.g.,
'WebKit_Linux/200/', and then keep looping, fetching old builds.

The whole directory listing process is really unnecessary. Most of the time
every build already exists and we can predict the file path, so querying
for it is just a lot of overhead. In addition, we already handle missing
builds just fine. So, I've replaced the logic with a simple in-memory loop
to populate the list of URLs.

In addition, we fetch actual build results in the order we return them, so
by returning them in ascending chronological order before, we would end
up fetching very old build results that we wouldn't need. Flipping the order
to descending chronological (most recent first) is another substantial speedup.

These changes cut down the load time for garden-o-matic by an 1-3 orders
of magnitude, depending on how many errors we have and what the actual
build numbers are.

R=eseidel@chromium.org, ojan@chromium.org
BUG=373846

Review URL: https://codereview.chromium.org/297513004

git-svn-id: svn://svn.chromium.org/blink/trunk@174465 bbb929c8-8fbe-4397-9dbb-9b2b20218538