Add hack to allow handling redirect to logs on the client properly.

This hack is temporary and should be removed when we find better
solution.

TL;DR: we can't handle redirects to S3 using CORS, so in case we want to
get logs from S3 without additional requests to API, we need to return
status that will not be automatically redirected (in this case 204 seems
like the best answer).

Longer rationale:

Old logs are hosted on S3 now and in case log is not available in the
database, we would like to redirect to the archived log. Although S3
support CORS, our use case breaks on some browsers:

  * when request is triggered to /jobs/:id/log and log is archived, api
    returns 302 redirect, Location header points to the log on S3
  * browser transparently redirects to given url, but it sets Origin to
    null, for security reasons
  * "Origin: null" is ok, because we allow every origin by setting
    AllowedOrigin to "*"
  * S3 returns "Access-Control-Allow-Origin: null" header, which breaks
    some browsers (I confirmed it for webkit based browsers)

In order to fix this, S3 would need to return * in
Access-Control-Allow-Origin header or we would need to tell the browser
to not follow redirect. Both solutions are not achiveable.

Another option would be to return log information in job payload - we
could send log_url field which should be either log url on amazon or
null, but in such case we would need to query artifacts table in each
job request. This is something that should be avoided as archived logs
are not frequently requested - slowing down every request to get info
for it would be a waste.