When calling `\OC\Files\View::copy` we should also keep the version to ensure that the file will always have the correct version attached and can be successfully decrypted.
To test this the following steps are necessary (from https://github.com/owncloud/core/issues/22781#issuecomment-191328982):
1. setup a new ownCloud 9.0 beta2
2. enable encryption
2. upload a docx (5.7MB large)
3. upload the same file again and overwrite the existing file
4. I can download the original file and the first version
5. I restore the first version
6. restored version can no longer be downloaded with the error described above
The manual cache operation in `\OCA\Files_Versions\Storage` is unfortunately necessary since `\OCA\Files_Versions\Storage::copyFileContents` is not using `\OCP\Files\Storage::moveFromStorage` in the case when an object storage is used. Due to the workaround added in 54cea05271 the stream is directly copied and thus bypassing the FS.
Some move operations when cross-storage will be replaced by copy and
delete. Before attempting this, first check whether the source storage
has delete permissions.
This also prevents renaming system-wide external storages.
When overwriting shared files as recipient, the part file is written on
the uploader's storage before overwriting the target file.
If the uploader has no quota left, they should still be able to
overwrite that file with Webdav. To make this work, they need to be able
to write the part file to their own storage first.
The encryption code uses partial cache entries for the part file (which
are not stored in the database) but are useful for other parts of the
code to retrieve the file size again.
This means that in the fixed code $info was empty, so getData() could
not be called.
The fix makes sure to support both cases when the cache entry exists and
doesn't.
Adding group Db to federation tests and ldap tests
Add group DB to Test_UrlGenerator
Adding group DB to trashbin and versions tests
Adding group DB to Test_Util_CheckServer for pg
