WIP: fix(encryption): store key by fileId for CollectiveMountPoint

[mejo-]

Summary

In Collectives, we can have different paths to a file by user (when a user changes their user_folder user setting). This leads to inaccessible files with server-side encryption as the encryption keys are stored by file path. In order to fix this, we should switch to fileId based key storage instead of file path based key storage.

TODO

• Decide whether we want to always store encryption keys by fileId, or just for ISystemMountPoint or just for CollectiveMountPoint
• Decide whether we change all the interfaces and functions to pass $fileId through encryption storage wrapper or whether it's acceptable to use $this->rootView->getFileInfo() in Util.php.
• [ ]

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[icewind1991]

I agree that storing keys by fileid would be an improvement, as it also removes the need to move the keys on renames etc.

Decide whether we want to always store encryption keys by fileId, or just for ISystemMountPoint or just for CollectiveMountPoint

I would be in favor of doing it for all storages, but that obviously makes migration/backwards compatibility harder

Decide whether we change all the interfaces and functions to pass $fileId through encryption storage wrapper or whether it's acceptable to use $this->rootView->getFileInfo() in Util.php

Ideally the fileid would be passed, (or just pass the full FileInfo instead of paths trough the whole stack)

[icewind1991]

This will run into problems with the number of files in a single directory. Some form of nested directory structure will need to be used to spread things out a bit

[mejo-]

Do you have an idea how we could nest the the files?

What do you think about a 3-level split of a 12-digit zero-padded version of the fileId? I.e. fileId 123 would go to 0000/0000/0123/123/, 987654321 would go to 0009/8765/4321/987654321/, and so on.

$padded = str_pad((string)$fileId, 12, '0', STR_PAD_LEFT); 
$path = substr($padded, 0, 4) . '/' . substr($padded, 4, 4) . '/' . substr($padded, 8, 4) . '/' . (string)$fileId;