Issue title: [UX] Gracefully handle 423 locked
 Issue body: Whenever a file is locked on the server, the client might receive the HTTP 423 Locked status code.
It will then show a red warning sign on the system tray icon.

Since this is an expected situation, I suggest to remove the warning sign and keep that failure silent. The client will usually try again later and it should succeed.
The client should still log the lock error in the activity log.

Maybe if the file failed uploading after 5+ attempty, it can then start showing visual warnings to the user ?

In the future, once the server-side transactional locking (aka experimental locking aka high-level file locking) is in place (currently disabled by default), such locking situations might happen more often in high-concurrency setups.

This ticket is more about improving the user experience in case a file is temporarily locked that has hopefully a high chance of succeeding the next time, nothing the user should have to worry about.

What do you think ? @dragotin @guruz @ogoffart 

@karlitschek as discussed

 Comments: 
 Comment 0: Great. I had this on my todo list too.
@dragotin what do you think? 
 Comment 1: So if i understand that correctly that would be as simple as putting the error 423 as a   `SoftError` in classifyError in `owncloudpropagator_p.h`

 Comment 2: Related to https://github.com/owncloud/client/issues/3490, but not the same as 3490 has server side involvement needed.

 Comment 3: In master "423 Locked" is now a soft error, which means it's not as noticable to the user and does not mark the sync as failed.

To trigger a restart of the sync I'd like to know which operations can lead to 423 @PVince81? Is it only for file uploads?

@dragotin @ogoffart Do you think we should promote such an error to NormalError if it happens too often? 

If we want to do that, I suggest we extend the "blacklist" table. It already has the purpose of tracking recurring errors between runs. We currently use it to hide known errors for some time. We'd now also use it to escalate repeated SoftErrors after a while.

 Comment 4: @ckamm it can also happen for other operations, for example if you try moving a folder while one of the files inside is being written by another process (exclusive lock).
 Comment 5: or deleting said folder
 Comment 6: @PVince81 Doh, thanks, that makes sense. :)

 Comment 7: Was backported to 2.0.2
 Comment 8: @ckamm I tested this issue
I have one quenstion. Thi is the steps tto reproduce
1. Go to the Desktop client
2. Create a New folder (e.g. ONE)
3. Go to the Folder ONE
4. Upload a file
5. Go to the Server Web with the same user
6. Rename the folder ONE for RENAME ONE, move the folder or delete the folder
7. Go to the Desktop client
8. You can see this error
![screen shot 2015-10-05 at 10 50 45](https://cloud.githubusercontent.com/assets/12032058/10277215/c82fdb12-6b54-11e5-8178-3606429aabbc.png)
And in de Desktop you can see this
![screen shot 2015-10-05 at 10 50 45](https://cloud.githubusercontent.com/assets/12032058/10277223/d3f2225c-6b54-11e5-8305-4f37bbc4b25b.png)

My question is: It the red icon should appear?, because @PVince81 said: Since this is an expected situation, I suggest to remove the warning sign and keep that failure silent. 

Thank!!
 Comment 9: Desktop v ownCloud-116.69.203.11566-nightly20151005.pkg  
Server v {"installed":true,"maintenance":false,"version":"116.69.203.115","versionstring":"8.1.3","edition":"Enterprise"}

 Comment 10: @Dianafg76 If I understand correctly you are renaming a folder on the server while a sync is running? I doubt that will trigger a 423 error on the client. I don't know whether there's a good way to manually trigger a 423 for testing purposes?
 Comment 11: @ckamm If I understand correctly you are renaming a folder on the server while a sync is running? Yes, That's right
 Comment 12: Log
```
10-06 09:49:05:050 0x7fd25a54a390 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5Folder38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5slotSyncFinished:   ** error Strings:  ("New Folder/IMG_0007.MOV: Error downloading https://docker.oc.solidgear.es:52827/remote.php/webdav/New Folder/IMG_0007.MOV-chunking-3011215277-19-5 - server replied: Not Found (File with name New Folder could not be located)")
10-06 09:49:05:050 0x7fd25a54a390 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5Folder38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5slotSyncFinished:     * owncloud csync thread finished with error
10-06 09:49:05:050 0x7fd25a54a390 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5Folder38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5slotSyncFinished: the last 1 syncs failed
```
 Comment 13: @ckamm 
Steps:
1. On the Desktop, Donwload one file
2. Go to the Server
3. Rename the Folder
4. Go to the Desktop client
5. Delete the same folder
After the download , on the desktop go to the activity option, and you can see :
![screen shot 2015-10-06 at 12 12 08](https://cloud.githubusercontent.com/assets/12032058/10306019/5c8dd7e4-6c24-11e5-9b0c-63505ad21bfc.png)

My question is : Is this correct or should be an error.
@ckamm Can you say what are the steps to reproduce this issue, please?

 Comment 14: Well, what happens here is: The client uploads chunks of a file to a directory which vanishes during the upload. So the upload to the old folder is not longer working - and the error message _server replied: Not Found (File with name New Folder could not be located)_ seems correct. 

In the next sync run, this should recover correctly. I do not see a simple solution to this.
@Dianafg76 do you agree?

 Comment 15: And btw, why @Dianafg76 might have seen a 423 Locked error here might be caused by this: During the rename of the target folder, the server might return the 423.

 Comment 16: @dragotin
In the next synchronization run , this should recover properly. I do not see a simple solution to this . I agree , it's what you're doing right now
 Comment 17: @Dianafg76 I do not really understand your last comment :smile: 
 Comment 18: @dragotin Sorry
I mean in the next synchronization run, It does it correctly
 Comment 19: @Dianafg76 which specific case are you having trouble with ?
 Comment 20: @PVince81 I 've written about two cases and I do not know if they are correct

 Comment 21: In general it is very difficult to reproduce a 423 error, unless you have a slow server/client and a lot of luck.

The best is to edit the server code and add a sleep() in the upload code, just before the final rename:
Before this line https://github.com/owncloud/core/blob/v8.2RC1/lib/private/connector/sabre/file.php#L171 add "sleep(10);".

Then:
1. Create a folder "folder"
1. Wait for sync
1. Upload a small file "test.txt" into "folder" with the web UI (it will spend a long time due to the sleep)
1. During the upload, on the client side (desktop client) rename "folder" to "folder2"

The rename should fail with 423 locked because the uploaded file is about to be put into that folder.
 Comment 22: @PVince81 I can't reproduce the issue, if I follow your steps and I have not had much luck .

 Comment 23: sorry, I made a mistake. You need to upload with webdav (cadaver) at step 3 because the "sleep" code path is only for webdav. I just tried it locally and could get the 423 error with sync client 2.0.1.

 Comment 24: @PVince81 ahhh, OK. Thanks
 Comment 25: I tried again with the sync client master and the while the 423 error appears in the activity log, it doesn't show a red warning, which is the expected behavior. After the lock was gone, the sync client tried again renaming the folder and succeeded.

 Comment 26: @PVince81, @dragotin 
I tried again with 
Desktop v ownCloud-116.69.203.11572-nightly20151008.pkg  
Server v {"installed":true,"maintenance":false,"version":"116.69.203.115","versionstring":"8.2 RC1","edition":""}
I can see on the Desktop a red warning
![screen shot 2015-10-08 at 17 00 25](https://cloud.githubusercontent.com/assets/12032058/10370398/e22f5d58-6dde-11e5-870c-7f2c4aa4e1fb.png)
 On Activity option I see
![screen shot 2015-10-08 at 17 00 48](https://cloud.githubusercontent.com/assets/12032058/10370408/ef861906-6dde-11e5-9982-a225e2613270.png)

After the lock was gone, the sync client tried again renaming the folder and succeeded.
![screen shot 2015-10-08 at 17 07 23](https://cloud.githubusercontent.com/assets/12032058/10370428/143f8f0c-6ddf-11e5-9013-0136a045afc1.png)

![screen shot 2015-10-08 at 17 07 46](https://cloud.githubusercontent.com/assets/12032058/10370435/2082e584-6ddf-11e5-9b34-c98e06fffec9.png)


 Comment 27: I didn't see any red warning in the system tray but didn't check the file overlay view. Is that a fancy addition on MacOS ?
 Comment 28: @PVince81 I've seen this on the log 
´´´
10-08 17:17:10:416 0x7fb803526d20 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5ownCloudGui38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5slotSyncStateChange: Sync state changed for folder  "ownCloud1" :  "Sync Running"
10-08 17:17:10:417 0x7fb803526d20 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5PropagateRemoteMov38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5start: virtual void O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5PropagateRemoteMov38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5start() "cadaver2" "cadaver23333"
10-08 17:17:10:417 0x7fb803526d20 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5AbstractNetworkJo38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5start: !!! O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5MoveJob created for "https://docker.oc.solidgear.es" + "/cadaver2"
10-08 17:17:10:556 0x7fb803526d20 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5AbstractNetworkJo38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5slotFinished: void O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5AbstractNetworkJo38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5slotFinished() 299 "Error downloading https://docker.oc.solidgear.es:52911/remote.php/webdav/cadaver2 - server replied: Locked" QVariant(int, 423)
10-08 17:17:10:557 0x7fb803526d20 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5PropagateRemoteMov38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5slotMoveJobFinished: void O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5PropagateRemoteMov38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5slotMoveJobFinished()  QUrl( "https://docker.oc.solidgear.es:52911/remote.php/webdav/cadaver2" )  FINISHED WITH STATUS 299 "Error downloading https://docker.oc.solidgear.es:52911/remote.php/webdav/cadaver2 - server replied: Locked"
10-08 17:17:10:557 0x7fb803526d20 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SyncEngin38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5slotItemCompleted: void O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SyncEngin38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5slotItemCompleted(const O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SyncFileItem &, const O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5PropagatorJob &) "cadaver2" INSTRUCTION_RENAME 3 "Error downloading https://docker.oc.solidgear.es:52911/remote.php/webdav/cadaver2 - server replied: Locked"
10-08 17:17:10:559 0x7fb803526d20 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SocketApi38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5sendMessage: SocketApi:  Sending message:  "STATUS:ERROR:/Users/Diana/newcadaver/cadaver23333"
10-08 17:17:10:560 0x7fb803526d20 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SyncEngin38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5slotItemCompleted: void O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SyncEngin38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5slotItemCompleted(const O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SyncFileItem &, const O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5PropagatorJob &) "cadaver2" INSTRUCTION_RENAME 3 "Error downloading https://docker.oc.solidgear.es:52911/remote.php/webdav/cadaver2 - server replied: Locked"
10-08 17:17:10:561 0x7fb803526d20 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SocketApi38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5sendMessage: SocketApi:  Sending message:  "STATUS:ERROR:/Users/Diana/newcadaver/cadaver23333"
10-08 17:17:10:566 0x7fb803526d20 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SyncEngin38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5slotItemCompleted: void O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SyncEngin38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5slotItemCompleted(const O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SyncFileItem &, const O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5PropagatorJob &) "" INSTRUCTION_NONE 0 ""
10-08 17:17:10:567 0x7fb803526d20 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SocketApi38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5sendMessage: SocketApi:  Sending message:  "STATUS:OK:/Users/Diana/newcadaver/"
10-08 17:17:10:568 0x7fb803526d20 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SyncJournal38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5walCheckpoint: void O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SyncJournal38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5walCheckpoint() took 0 msec
10-08 17:17:10:569 0x7fb803526d20 O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SyncJournal38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5commitInternal: void O38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5SyncJournal38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5commitInternal(const QString &, bool) Transaction commit  "All Finished." 
´´´

 Comment 29: Yes this is expected.

The purpose of this ticket is only to not bother the user with error displays when a locking situation happens. From what I see this is already fixed properly since the system tray doesn't show the error any more, and the error appears in the activity log, which is also expected.

The question now is whether the file list overlay should still show an error for locking issues or whether it should also stay green ?
 Comment 30: I don't now
@dragotin,  can you help us?

 Comment 31: hmm, probably not an error, but the sync icon should stay.
 Comment 32: I can reproduce this and see the `STATUS:ERROR:folder2` that the socket api emits.

 Comment 33: I suspect this is a bug in the Mac overlay icons.

Background:
- When a sync job completes, the socket api currently always sends `OK` or `ERROR`. That means currently every file with a SoftError will be set to `ERROR` state. For the particular test case of renaming "folder" to "folder2" while "folder" is locked, this will result in the `STATUS:ERROR:folder2` message.
- However, when the file status for "folder2" is queried, the result will be `STATUS:NEW:folder2` because the new folder has never been synced correctly.
- In nautilus, the folder correctly shows the blue sync icon.

We should rethink the status we send to connected clients when a sync item completes. I believe it should be the same status we'll send on subsequent `RETRIEVE_FILE_STATUS` queries. This is a change I don't want to make in the 2.0 branch.

 Comment 34: @Dianafg76 @PVince81 Thanks for confirming that the error handling works and pointing out the odd behavior with the overlay icon on Mac. I'll close this bug for 2.0.2 and make a new one to fix the overlay icon display for these kinds of errors - that issue applies also to other soft errors.

 Comment 35: Agreed
{'source': 'GithubIssues', 'repo_name_with_owner': 'owncloud/client', 'issue_id': 92274043, 'repo_stars': 1313.0}