Discovery: No fatal error on bad server response

[ckamm]

Previously receiving unexpected replies from the server during discovery
would terminate the sync run with a fatal error. Now it only causes an
error on the affected item.

For #6826

[ogoffart]

The test was making sure that the filename where the problem occurs is in the error message. This should stay.

Edit: Ok, not needed since the error is on the file itself.

[ckamm]

Since the error is now located on the affected item it's no longer necessary to include the file name in the message itself. We do appendErrorString(QObject::tr("%1: %2").arg(item->_file, item->_errorString));

[ogoffart]

This sounds like a dangerous change.

It is true that this is now made possible to ignore part of the tree with the new discovery.

What happens if the server suddenly goes in maintenance or away? Do we get many ignore "error".

If a file is moved to a directory which now errors, the file will simply be deleted. Is that ok?

[ckamm]

Yes, doing discovery with partial remote information would affect things like renames/moves in the way you mention.

And thinking about it more, I agree that it's a bad idea to open the sync algorithm for this kind of complication. If we look a the user issue "my remote discovery takes very very long and if it has any kind of error it has to start from scratch" it's likely that we can solve this in another way (like the discovery cache we talked about) without starting to sync when we know we don't have an up to date remote snapshot.

Note: The maintenance mode (503) behavior already works in this way: it was already handled by ignoring the folders where the error appeared.

[ckamm]

I'll extract some changes from this patch and open a new PR with these.