[FR] Ability to expose file revisions from ZFS/BTRFS snapshots/rsnapshot backups instead of OC managing its own file duplicates
Is your feature request related to a problem? Please describe.
The current implementation of file revisions needlessly wastes space if there is already a system in place that makes previous file revisions directly accessible as files (e.g. ZFS/BTRFS snapshots, rsnapshot-style backups, ...).
Describe the solution you'd like
I'm imagining something like the Snapshots app for Nextcloud, i.e. a way to tell OpenCloud that instead of looking for & creating self-managed CURRENT and REV.* files in .oc-nodes directories, the admin could tell it where (and under what naming scheme - to match e.g. .zfs/snapshots/auto-20251018.0015-2w/ or daily.0/, daily.1/, weekly.0/ and so on) to find previous copies that already exist. Since this would show a lot of revisions, the found files/revisions should be stat'ted (chronologically backwards) and only files with a differing mtime and/or size counted as an actual revision. (Comparing checksums would be safer of course, but doing that on the fly would be very resource-intensive, and computing them once and store them somewhere opens up a whole can of worms. However, in this backup context, files that are identically named, sized and mtime'd but have differing contents should be exceedingly rare, and e.g. rsync defaults to the same behavior.)
Describe alternatives you've considered
Some external scripting solution that replaces OpenCloud's CURRENT/REV files by some hard/symlink magic could potentially work, but seems very brittle and plain wrong.
Additional context
Implementing this would also very neatly delegate the problems mentioned in #959 and #1419 to what the admin has already configured in the backup system.
cc @tbsbdr