This code being here has a code smell to it. As per `oae-content/lib/backends/remote.js#getDownloadLink`, a remote URI should be redirected to. Here we are externally hijacking that contract and making a direct link despite what it is saying to do.

I can see the benefit to direct-linking to remote URLs rather than redirecting through our download endpoint, but I'm wondering if we consciously opted to not do it this way -- was it some caching oddities? /cc @simong 

If direct linking like this is fine, there might be a better way to accommodate this, helping the content API determine how to create this download url. Here is something I have in mind:

1. Let the backend determine a "Download Strategy" instead of a "link" that consists of a strategy name and a "target". The name could be `DIRECT`, `REDIRECT` or `INTERNAL`
  * REDIRECT (`"code": 302` at the moment) and INTERNAL (`"code": 204` at the moment) are always signed and always go through `/api/content/download/...`
  * DIRECT (a new strategy) will just give the second portion of the uri
  * e.g., I think Amazon S3 could be DIRECT because it is a URL that is secured by amazon (i.e., it doesn't need to bounce through our  signing mechanism, same thing with the Remote uris)

2. When the content API generates the target for the UI (basically what is happening here), it can key off of the download strategy to determine if the generated URL should pass the target through `/api/content/download..`, or if it should use the target directly

This implies that the `getStorageBackend(ctx, revision.uri).getDownloadLink(ctx, revision.uri);` method (which may be renamed to getDownloadStrategy) would be invoked **before** generating the URL for the UI. It would also be invoked afterward if the if the download url specifies to pass back through `/api/content/download/...`