fix: allow copy or move on ownerless mounts when no new shares are added

[salmart-dev]

• Addresses Scenario 3 reported in: [Bug]: Folder creation/renaming failed on team folders with share #56727

Summary

Currently, when a user with no sharing permissions tries to move files inside a mount which has also been shared by other users, the move is blocked in all cases. This PR changes this, so that the move or copy is allowed to happen if it would result in the file not being exposed into additional shares than the current ones.

UX Notes:

1. this makes it possible for a user without share permissions to move files in a location that is not part of a share, but prevents them from moving the file back in the old location, as that would mean sharing the file.
2. operations that involve link shares are still blocked, as it is not possible to use this logic with those shares: it's not possible to know whether the user has access to that share or not

Technical Note: initially I wanted to use the mounts table for this, but unfortunately in the situation where a mount already exists and the share is a group share (or any share that does not clear the user's mount cache) it results in the fix working only once the full file-system setup is triggered.

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

[salmart-dev]

/backport to stable35

[salmart-dev]

/backport to stable34

[salmart-dev]

/backport to stable33

[provokateurin]

this makes it possible for a user without share permissions to move files in a location that is not part of a share, but prevents them from moving the file back in the old location, as that would mean sharing the file.

Not sure about this, it moving a file out of a share should probably also require share permission in this case. Alternatively it should require delete permission on the source node, as moving a file out of a share is effectively deleting it for the share recipients. Not sure which one is the better solution, maybe it should even require both (as does moving a file into a share, since that requires create+share permissions).

[salmart-dev]

Not sure about this, it moving a file out of a share should probably also require share permission in this case. Alternatively it should require delete permission on the source node, as moving a file out of a share is effectively deleting it for the share recipients. Not sure which one is the better solution, maybe it should even require both (as does moving a file into a share, since that requires create+share permissions).

The logic that I followed is: the user has delete permissions on the storage, so technically they should not be denied deleting or moving a file. However, they lack the sharing permission, so they should not be able to expose data to new shares. In this context, there is nothing saying that the user should not be allowed to move files out of a share, so I would not block it. If this is a use-case we want to support, we should then put it into a feature request.