Avoid locking on restore/delete and limit concurrent requests

[juliusknorr]

Summary

This is a frontend safeguard to avoid running into backend file locks when deleting or restoring multiple files. Even after https://github.com/nextcloud/server/pull/28438/files#diff-5450a6734b54a8b5e2c2f7521098ba6d05993e8bbebffeee140e93ec349e4127R978 this could still happen if the retry timeout was exceeding 15 seconds.

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)

[szaimen]

🐘

[icewind1991]

I think it's fine to change the scanning logic to only scan 'files_trashbin/versions/'. $filename instead of 'files_trashbin/versions/', which should help prevent conflicts

Edit: that doesn't work as they don't have a common parent but are instead named "$filename.vXXX.dXXX"

[icewind1991]

Note that I'm not sure if the scan logic is still needed, I know that in the past we didn't actively maintain the cache outside of /$user/files but I believe that is no longer the case

[juliusknorr]

Note that I'm not sure if the scan logic is still needed, I know that in the past we didn't actively maintain the cache outside of /$user/files but I believe that is no longer the case

I had the same assumption in https://github.com/nextcloud/server/pull/28438/files#r691270467 so should we just drop it?

[juliusknorr]

Deleting and restoring versions seems to still work fine with that code part removed.

[icewind1991]

Do we want to increase the concurrency a bit if we remove the scan?

[juliusknorr]

Increased to 4 which seems a reasonable value for now.

[icewind1991]

/compile

[juliusknorr]

/backport 7f913de to stable25

[juliusknorr]

/backport 7f913de to stable24