* fixes#22819
The old way fired a DELETE statement on each destruction of the
DBLockingProvider. Which could cause a lot of queries. It's enough
to run this every 5 minutes in a background job, which in the end
could result in file locks that exists 5 minutes longer - in the
worst case and for not properly released locks.
This makes the DB based locking a lot more performant and could
result in a similar performance to the Redis based locking provider.
Whenever a file was deleted (also from trash), the tag mapping is
pointing at a fileid that doesn't exist any more.
This cleanup job will delete such orphaned mapping entries.
There is no need to calculate a human readable date on the server side.
We supply the mtime and a client can easily convert that himself if
needed. This is already done most of the time since the date is often
not in the exact right format.
There is also no need to attach icon info. We have that available in
javascript. And else the client should get the right icon based on the
mimetype for its platform.
* Updated tests
When renaming over the web UI, check early that the target name is
valid.
This prevents nonsensical error messages when renaming to a name with a
trailing backslash.
`\OCA\Files\Helper::buildFileStorageStatistics` might throw an exception from `OC_Helper::getStorageInfo`, previously this lead to a uncatched exception being thrown when invoking this methods.
This was user triggable by for example calling `/index.php/apps/files/ajax/delete.php` with a not existing dir (for example `dir=asdf/../&allfiles=true`)
This fixes an issue when renaming files from a flat list view like
"Favorites" or "Shared with you", in which case the path needs to be
present in the response to make sure the data-path attribute is properly
set in the JS side.
To make it possible for the web UI to correctly display the tag/favorite
information after a rename, this information is now returned in the
rename response