Desktop respect file/folder permissions on shares / groupfolders

[tobiasKaminsky]

Change in client behavior respecting the file permissions from the server, which isn't yet the case for all scenarios.

• in case of a by another user locked file the desktop client sets the file to read-only (correct)
• for a shared file that is shared only with the read permission, the file should also be marked read-only on the desktop client (todo)
• for a groupfolder where the user also only has a read permission , the file should also be marked read-only on the desktop client (to check if this is already the case, else also a todo)

currently the 1 or 2 last items aren't the case. So in case you open an office document, you can open it with local write permission. the saving to the server obviously failed yet a temporary file gets created which the client tries to upload which also failed since the whole folder is shared read-only. So in these scenarios the files in question should be marked read-only like the client does for server-side locked files.

[mgallien]

I pushed a proof of work PR
seems like using the c++17 API is working and should get this done easily
will need to make sure every code path is covered and add automated tests

[mgallien]

some things were not anticipated causing a bit more work
I need to put a read-only folder in read-write mode when propagating server changes and then put back the proper permissions
Up to now, that seems viable but this was missed when discussing the amount of work to do.
The changes to do this are ready on local but I expect that testing and review will take a bit more time due to that added complexity

[mgallien]

fixed regressions in automated tests due to read-only folders being really read-only
will now add more automated test scenario to cover the new feature needs:

• if a folder was read/write and is now read-only, ensure it still works
• if a folder was read-only and is now read/write, ensure it still works
• ensure test coverage with virtual files on windows

[mgallien]

I encountered an unexpected issue
on the PR, AppImage is failing to build due to partial support for the needed c++ norm (i.e. c++-17) from the current image
this image is based on ubuntu-18.04 that was supposed to be the one needed by the tooling we use to build AppImage
I have been working on upgrading the docker images related to desktop client to overcome this
the time needed to do that was not taking into account when estimating the remaining work
I worked on this already for the last 2 work days delaying other remaining to-do items to complete this task
this is going to block any merge as we would be unable to release the desktop files client for Linux anymore
see nextcloud/docker-ci#626

[mgallien]

following the changes of basing the container that is used to generate AppImage packages (i.e. releases) on ubuntu 20.04, we effectively loose compatibility of the older ubuntu 18.04 LTS (that one is no longer actively supported by ubuntu)
@tobiasKaminsky
I suggest to move on and handle this from the client updater server and our communication

[mgallien]

we would also need to move the requirements even higher up when moving to Qt6 (see https://doc-snapshots.qt.io/qt6-dev/supported-platforms.html#linux-x11)

[mgallien]

I eventually just tested ubuntu 20.04 and AppImage generated from ubuntu 20.04 will indeed run well on it

[mgallien]

I pushed changes to test (and make it work) to have folders change between read-only and read/write
remaining tasks (from my current understanding) :

• test with virtual files on windows (in particular with implicit hydration and forcing files/folders to be always available offline)
• review