Relocate repository for ImageInfoList service

[jimk-bdrc]

As part of researching how to fix archive-ops 506, I realize we should think about using a different repository from the images to store information about them. There are two reasons for this:

• AO builds Distribution packages for other repositories who are very intolerant of anything except images in their repositories. We spend a full 5% of our programming and testing time having to filter out the json files from the images.
• When we run into issues which only require a rebuild of the manifest, we can do that without touching the images themselves.

We could just use a different folder under the same work (meta/ or a new one, perhaps manifest The work would be straight forward, just simultaneously changing /images/ with /manifest (or equivalent) in:

1. buda-iiif-presentation.ImageInfoListService.java

    return "Works/" + md5firsttwo + "/" + imageInstanceLocalName + "/images/" + imageInstanceLocalName + "-" + imageGroupLocalName + "/dimensions.json";

2. change the Python volume_manifest_builders generators' ImageRepositoryBase.getPathFromLocators from

        return f'Works/{two}/{work_Rid}/images/{work_Rid}-{image_group_folder_name}/'

There's a little more work on the Python side, because v_m_b assumes its input and output folders are the same, but that's not big deal.

There will be a short migration process while we move all the existing dimensions.json and 'fileList.json` to their new homes.

wdyt?

[TBRC-Travis]

yes, I think this is a good idea. i'm in favor of storing them in the meta folder.

[eroux]

sure, works for me

[jimk-bdrc]

Juste realized, we'll have to add them all before Elie can use it. Scheduling is the issue.

[jimk-bdrc]

A better way would be to leave them out of the images stream, and only recombine them when DIPping to the s3://archive.tbrc.org/Works stream.

See buda-base/volume-manifest-builder/48