bundle_id generation

[benjaminran]

Bundle id is generated by hashing manifest.tsv values from the columns referenced by workflow_uuid_keys (currently ["sample_uuid", "workflow_name", "workflow_version"]). This means that updating other fields in the manifest won't change the bundle_id generated, in which case the metadata-server won't update the metadata redwood tracks (i.e. projectCode).

This can cause things like

ERROR perform_upload:496 error while uploading files
ERROR: Command error: java.io.IOException: Storage client error: Token missing required scope to update project

(in this case because the token used has access to the new project, but not the previous project under which this sample_uuid/workflow_name/workflow_version were initially registered)

It would be nice to add program (and maybe other fields?) to the workflow_uuid_keys, but we should make sure it will still be possible to update existing bundles; receipts from past uploads should be usable as the core-client input manifest.tsv and their bundle_id should be respected (rather than regenerating a new hash over different fields that'll yield a totally different bundle id for the revision).

[wshands]

It will probably be too restrictive to future development to require backward compatibility with receipts from past uploads. Users may simply download a new manifest and use that to download files from the storage system.