Clean up and improve how mismatching resolutions are detected

[philippotto]

The nightly test fails in one test case due to "mismatching resolutions". However that failure was a false positive, which is caused by the fact that we keep the original resolutions per layer instead of storing the "densified version". The code had problems with a dataset where the resolutions were like this:

• mag 1, mag 2, mag 4, mag 8
• mag 32

The old code densified the resolutions (i.e., padded all the missing resolutions for the second layer) and assumed that the longest resolution list covers all resolutions. The new code constructs a union of all resolutions and checks that there are no mismatches while doing so.

URL of deployed dev instance (used for testing):

• https://___.webknossos.xyz

Steps to test:

• see new automated tests
• execute nightly

Issues:

• follow-up to Multi-Resolution Volume Tracings #4755

---

• Updated (unreleased) changelog
• Updated (unreleased) migration guide if applicable
• Updated documentation if applicable
• Adapted wk-connect if datastore API changes
• Needs datastore update after deployment
• Ready for review

[philippotto]

The nightly succeeded 🎉 See https://app.circleci.com/pipelines/github/scalableminds/webknossos/1683/workflows/d378dc18-d171-478f-8181-51bb928acff1/jobs/12880

[daniel-wer]

Nice fix and it makes sense to me. Impressive how well the longest-list-covers-all-resolutions heuristic hold up 🙈 Thanks for adding the tests and for confirming the fix by running the screenshot tests 🎉

[philippotto]

Impressive how well the longest-list-covers-all-resolutions heuristic hold up see_no_evil

I think (but maybe I'm missing something), the previous logic was quite "precise" (but not elegant 😆), since the resolutions were always "densified" (starting at mag 1 until the maximum) in the initialization. Therefore, essentially the range from "mag 1" to "highest mag" was used, which is probably equivalent to the new way (building the union and then densifying it).