Add mirror URI column to compact manifest

[hannes-ucsc]

Should it point to the info or file object? Do we really need it, given that the file_url column points back to Azul which checks the info object, and given that it can be easily derived from the sha256 column. On the other hand, the bucket name is not obvious and also which digest to use. So it may be easy for us to derive but not necessarily for the user.

[hannes-ucsc]

We can't afford to check for the existence of the info object for every file while generating the manifest.

The shortcut method of accessing file objects directly is documented and accounts for the fact that the file may not have been mirrorred or that its content may not match the digest. Given that, we can include a azul_mirror_uri column in the manifest and populate that column with the speculative s3://… URI of the file object for each file entity matching the filter.

[hannes-ucsc]

For demo, generate a small, compact manifest in dev and use aws s3 cp to download a few of the URIs in the manifest. Generate a manifest in prod and use aws s3 cp --no-sign-request to download a few of the URIs in the manifest. Generate a manifests for a LungMAP catalog in dev and prod. Show that the aws s3 cp command fails for a few of the URIs in those manifests.