Test multi-plate support in cellvoyager converter

[tcompa]

Current situation:

1. The create-ome-zarr task accepts a list of N input_paths, which are then treated as independent plates and processed one by one - leading to N OME-Zarr files.
2. The copy-ome-zarr task (soon to be partly refactored, see Extend/improve copy-zarr task #279) only supports len(input_paths)=1, but in this folder there may exist N OME-Zarr files, for instance because of what was described in point 1. In this case, the copy-ome-zarr task loops over the N independent plates and copies them into N new OME-Zarr's.
3. Note: it's not fully clear what would happen if we call the copy-ome-zarr task twice on the same folder. I think that the first time it will create a plate_mip.zarr copy of the original plate.zarr, while the second time it will attempt creating copies of both plate.zarr and plate_mip.zarr, likely resulting into errors.

As part of last week meetings, we mentioned that this is not necessarily a crucial feature, but for sure it does add up to the task complexity. Question: should we fully drop it?

If so, the new version would be:

1. The create-ome-zarr task only accepts a single input folder, while multiple input folders only make sense for its multiplexing version.
2. The copy-ome-zarr accepts a single input folder (which is already the case) and checks that this folder only has a single OME-Zarr.
3. A more fine-grained operation in a folder which includes multiple OME-Zarr's would not be immediately supported. Most likely it would require additional inputs from the user (possibly related to Replace parallelization_level with more structured options of what to run fractal-server#792), and it would also depend on Turn input_paths into zarr filenames? #324 and Enable 2D to 3D workflows #342, and on the future way of storing MIP projections in the same OME-Zarr.

[jluethi]

From a use-case side: I agree that we can move support for processing multiple "unrelated" input plates to be processed as separate datasets, not the same dataset with different components. It may even be the better user experience to encourage that way of processing, because a user may decide mid-way during processing that different plates actually need different workflows.

The copy-ome-zarr accepts a single input folder (which is already the case) and checks that this folder only has a single OME-Zarr.

It should be possible to run this in a folder that e.g. contains plate.zarr and plate_mip.zarr (or any other collection of zarr files that aren't in the component list). Can't it just work on the metadata plate list (that contains a single plate name)?
Why it's important that it works that way? Because we'd want to run the new, more flexible copy OME-Zarr task e.g. on the plate_mip.zarr again to test on a subset of the MIP dataset.

This then also opens the larger question: Should our tasks in general take a list of input datasets, if it's only needed for the Convert OME-Zarr multiplexing?

[jluethi]

I tested it now in #812

With fractal-tasks-core 1.2.1, it already basically works. It creates multiple plates and converts the images correctly. It even handles getting plates of the same name.
It didn't correctly handle the plate metadata for the image list in that case yet, and that will come with #812 marking multi-plate support officially supported & tested