Option for bearer-token protected batch job result URLs

[soxofaan]

(This is spin-off of the discussion at #380)

Batch job results currently have to be published as signed URLs that do not require bearer auth or other headers, to make it possible to download the results in applications where it is hard to set the necessary headers.

Signed URLs however come with some security disadvantages: they are simple URLs that give direct access to resources that we normally protected with real authentication in other parts of the API. Expiry times should mitigate the security risk and there is currently a proposal to also allow invalidating of signed URLs (see #341/#381). However, a back-end is currently not required to support any of these solutions.

An alternative to signed URLs for batch job result downloads is using the standard bearer auth headers we use elsewhere. This is probably trivial if the back-end stores the result files itself, but even if the results are on third party storage it should be possible to proxy these results through backend URLs.

possible solutions:

• add a request parameter to /jobs/{job_id}/results to toggle between signed URLs and http header based download URLs
• change the single href field under the assets items in the response to a list of multiple URLs: e.g. in pseudo code [{"type": "signed", "href": "https//s3.com/...."}, {"type": "auth", "href": "https://backend/...."}]