feat(syncengine): fail and restart the sync if discovery is suspicious - #9572

Especially with many file changes incoming, by the time the sync
actually starts the local discovery list might not have caught all
changes yet.

Signed-off-by: Jyrki Gadinger <[email protected]>

Apparently there was a change in Windows which causes the low-level APIs
for iterating over directories to not return all contents when iterating
over a just-changed folder that has cfapi enabled.

The file system watcher might have already caught the changes, but it
could still be that during discovery those APIs are returning the wrong
state.  This is especially awful when folders are moved, as the rename
detection will not work.  In this specific case what happens is the
following:
- First sync run: during discovery only the origin folder is discovered
  as missing.  Propagation: remote DELETE of the origin folder, and the
  sync DB is cleaned from all files inside that directory.
- Second sync run: the sync engine detects the target folder, but the
  placeholder files inside it are unknown as they had been removed from
  the sync DB.  As the folder structure is present locally, the folder
  tree will be propagated remotely, and all local virtual placeholder
  files are removed from the file system.

Therefore, to be on the safe side: fail the sync after discovery if
there was at least one deletion once.  A follow-up sync attempt is
assumed to then have the correct view of the file system again.

See also: #8983

Signed-off-by: Jyrki Gadinger <[email protected]>

add extra sync runs as needed

Signed-off-by: Matthieu Gallien <[email protected]>
Signed-off-by: Jyrki Gadinger <[email protected]>

Signed-off-by: Jyrki Gadinger <[email protected]>