fix(files_sharing): Hide own reshares

[provokateurin]

• Resolves: [Bug]: Reshare with (own) group ends up as double share for sharee #51988

Summary

Another attempt at #51988.
The fix is the same, but I've dug deeper into the issue and found that the integration tests don't transfer incoming shares when doing the ownership transfer. Just enabling incoming share transfer would have been enough, but this actually pointed to problem that we currently break reshares when doing ownership transfer without incoming shares.
The original user will still have the incoming share, while the outgoing (re-)share is transferred to the new user. My fix for hiding own reshares assumed, that one would always have access to the original share when you have a reshare for it.
With the partial ownership transfer this is not true and I believe this is wrong as we must always transfer all shares to guarantee that reshares are still working as expected.

This will require some changes in Talk integration tests because paths have changed:

diff --git a/tests/integration/features/sharing-4/transfer-ownership.feature b/tests/integration/features/sharing-4/transfer-ownership.feature
index cbf596344..12f547f0f 100644
--- a/tests/integration/features/sharing-4/transfer-ownership.feature+++ b/tests/integration/features/sharing-4/transfer-ownership.feature@@ -65,11 +65,11 @@ Feature: transfer-ownership
| displayname_owner | participant2-displayname |
| uid_file_owner | participant3 |
| displayname_file_owner | participant3-displayname |
- | path | /welcome (2).txt |+ | path | /Talk/welcome (2).txt |
| item_type | file |
| mimetype | text/plain |
- | storage_id | shared::/welcome (2).txt |- | file_target | /welcome (2).txt |+ | storage_id | shared::/Talk/welcome (2).txt |+ | file_target | /Talk/welcome (2).txt |
| share_with | group room |
| share_with_displayname | Group room |
And user "participant2" gets last share
@@ -78,10 +78,10 @@ Feature: transfer-ownership
| displayname_owner | participant2-displayname |
| uid_file_owner | participant3 |
| displayname_file_owner | participant3-displayname |
- | path | /Talk/welcome (2).txt |+ | path | REGEXP /^\/Transferred from participant1-displayname on [0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}-[0-9]{2}-[0-9]{2}\/welcome \(2\)\.txt$/ |
| item_type | file |
| mimetype | text/plain |
- | storage_id | shared::/Talk/welcome (2).txt |+ | storage_id | REGEXP /^shared::\/Transferred from participant1-displayname on [0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}-[0-9]{2}-[0-9]{2}\/welcome \(2\)\.txt$/ |
| file_target | /Talk/welcome (2).txt |
| share_with | group room |
| share_with_displayname | Group room |

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)

[come-nc]

Code-wise this is okay, but I’m not sure about the design decision.
There might be no reshares, do we really want to remove the possibility to transfer ownership without incoming shares?

[come-nc]

Also, transfer takes a path to transfer ownership only of a folder, but with this PR all incoming shares including outside of this path will be included I think?

[provokateurin]

There might be no reshares, do we really want to remove the possibility to transfer ownership without incoming shares?

TBH I don't see why we have it as an option in the first place. The PR that added it has no explanation or review comments that give a reason for the option to exist.

Also, transfer takes a path to transfer ownership only of a folder, but with this PR all incoming shares including outside of this path will be included I think?

I didn't look into it because I thought this was already done correctly, so I suppose this is another bug with the existing implementation outside of the bug I'm trying to fix (but of course I will fix it as well).

[provokateurin]

/backport to stable31

[provokateurin]

/backport to stable30

[provokateurin]

Marking as draft for now, as I still want to address @nickvergessen's comment.