WIP: Unified annotation versioning

[fm3]

URL of deployed dev instance (used for testing):

• https://___.webknossos.xyz

Steps to test:

• abc

TODOs:

• Mechanism to Revert Editable Mappings
  • Iterators for SegmentToAgglomerate, AgglomerateToGraph
  • How to encode Reverted chunks, agglomerates? → Single Zero-Byte?
    • Check a single zero byte is not a valid proto message
  • Iterate over current version, fetch old version, rewrite
  • Integrate this in Updater or flush Updater before this happens
  • Test
  • Cleanup: Generic Reversion-Aware Iterator? Build on top of VersionedFossilDbIterator?
  • Save perf by skipping fetching content when only version is needed in iterator (different from volume, because here we don’t need to update the segment index)
    • that might need new fossildb api (ListKeysWithVersions)
  • Make the iterator async?
• Annotation proto object
• Annotation-wide update actions
  • add layer
  • delete layer
  • update layer metadata
  • update annotation metadata (name+description)
  • should “duplicate” also copy update actions? This is currently the case only for editable mappings. Needed for its merge function
• Update Actions as Proto?
  • How to apply?
• Unified versioning over layers
  • Route
  • Store Updates
  • Create Annotation
  • Updates need Layer Identifier
  • Apply Updates
    • updates that mutate annotation object
    • updates that mutate tracing objects
    • updates that mutate other stuff
      • volume buckets
      • proofreading
    • Special updates
      • AddSegmentIndex
      • ImportVolumedata
      • makeMappingEditable
      • Merge?
      • RevertToVersion
  • Version assertions
  • lazy apply for volumes and editable mappings?
    • can volume data still be written directly? can there be conflicts?
    • or ditch lazy apply completely? (might be ok with distributed skeletons etc)
    • When to materialize which layer?
      • store materialized layer only sometimes? count its update actions?
• Search for // TODO
• Renamings
  • Annotation to AnnotationInfo, AnnotationLayer to AnnotationLayerInfo
  • Tracing to AnnotationLayer
• Frontend
  • Linearized update actions
  • Use new update action route
  • update actions now need actionTracingId
  • updateTracing was renamed → updateVolumeTracing/updateSkeletonTracing
  • Version Restore View
  • Send latest description + name with update, next to segment/tree stats?
  • enforce revert actions to come in separate update requests
  • same for add layer / delete layer / initialize editable mapping
• Migration
  • Linearized Updates
  • changed update actions
    • updateTracing was renamed → updateVolumeTracing/updateSkeletonTracing
    • update actions now need actionTracingId
  • Find annotation ids
  • Can we run a first part in the background?
  • editable mapping update actions used to be stored by mappingName, now annotationId

Issues:

• fixes Unified Annotation Versioning #7839

---

(Please delete unneeded items, merge only when none are left open)

• Updated changelog
• Updated migration guide if applicable
• Updated documentation if applicable
• Adapted wk-libs python client if relevant API parts change
• Removed dev-only changes like prints and application.conf edits
• Considered common edge cases
• Needs datastore update after deployment