First-pass listen to zarr, reconstruct, and fill napari layers

[talonchandler]

This is a rudimentary, single-threaded attempt at our "listen-to-zarr" strategy.

@ziw-liu I ran into at least three challenges this afternoon/evening:

• when should I create my output zarr, and with what metadata? I ended up using a strategy similar to our earlier create_empty_zarr, but now I don't know the number of time points in advance, so I needed to create it for the first time point then append for subsequent time points.
• how should I use the existing reconstruction API to reconstruct one time point at a time as it arrives? For better or worse, the API mimics the CLI, so the API writes into an existing zarr. Unfortunately, this conflicted with the unknown number of time points, so I have a workaround in this branch where I write the reconstruction to a tmp.zarr then copy it into the final .zarr. We may need to rework the API...but I think this suboptimal strategy can work for now.
• what's the best strategy to create napari layers with a variable/changing size? I couldn't manage to get the napari sliders to update when I appended data to a zarr without removing then replacing the layer. Have you tried this?

Many of my difficulties stemmed from the unknown number of time points. Clinton assumed that he knew the number of times, right? Would relaxing this constraint make sense for tomorrow?

[codecov]

Codecov Report

Merging #451 (4976c37) into v1-gui-layout (4363c7f) will decrease coverage by 0.77%.
Report is 24 commits behind head on v1-gui-layout.
The diff coverage is 1.40%.

@@               Coverage Diff                @@
##           v1-gui-layout    #451      +/-   ##
================================================
- Coverage           8.86%   8.09%   -0.77%     
================================================
  Files                 29      31       +2     
  Lines               4547    4866     +319     
================================================
- Hits                 403     394       -9     
- Misses              4144    4472     +328     

Files	Coverage Δ
recOrder/tests/cli_tests/test_compute_tf.py	100.00% <100.00%> (ø)
recOrder/tests/cli_tests/test_reconstruct.py	100.00% <ø> (+2.85%)	⬆️
recOrder/tests/cli_tests/test_settings.py	100.00% <100.00%> (ø)
recOrder/tests/conftest.py	100.00% <ø> (ø)
recOrder/tests/util_tests/test_io.py	100.00% <ø> (ø)
...er/tests/widget_tests/test_sample_contributions.py	100.00% <100.00%> (ø)
recOrder/scripts/launch_napari.py	0.00% <0.00%> (ø)
recOrder/scripts/samples.py	0.00% <0.00%> (ø)
recOrder/scripts/watch_zarr.py	0.00% <0.00%> (ø)
recOrder/plugin/_widget.py	0.00% <0.00%> (ø)

[mattersoflight]

@talonchandler , @ziw-liu I think it is fine to use vanilla zarr or dask if it makes lazy loading of zarr easier than with iohub.

what's the best strategy to create napari layers with a variable/changing size? I couldn't manage to get the napari sliders to update when I appended data to a zarr without removing then replacing the layer. Have you tried this?

I am not sure if this is the best, but dask.delayed seems viable.
https://napari.org/stable/tutorials/processing/dask.html

[talonchandler]

@ziw-liu and I chatted and agreed that we should assume a finite (and known) number of time points. This lets us use the existing CLI. I've updated this branch with a first-pass implementation.