This is better, as Cuirass will return a build for the derivation it built to
generate that output. This avoids having to query for multiple derivations
that generate a single output, until the one that Cuirass used is found.
The equivalent_derivations table was an experiment that didn't work, so switch
to using the derivations_by_output_details_set table.
Also take the build server id as input, as this allows selecting derivations
which have no known build for the relevant build server.
Rather than eliminating any derivation that has a known build, eliminate those
derivations, but also equivalent derivations as well.
For selecting the derivations in a revision, join on the equivalent
derivations, as all the equilalent derivations need checking as well, as it's
unknown which one Cuirass would have associated the build against.
Also, filter for x86_64-linux, to avoid checking for crossbuilt things. This
should be replaced by some way of describing what derivations a build server
has.
Cuirass provides a timestamp field in build responses, and sometimes this
means when the build was scheduled, but when the build is finished, it's the
stoptime.
So only use the timestamp when the build hasn't finished.
Allow for build status information to be submitted by POST request. This
required some changes to the builds and build_status tables, as for example,
the Cuirass build id may not be available, and the derivation may not be know
yet, so just record the derivation file name.
