In case two renames are done on the same file/folder very quickly we
lost the information that the second operation was also a rename. That
was because we tried to get the inode value from a stat on the file once
the first rename was finished. But at that point, the file was already
gone because of the second rename.
Now the original inode is kept and written to db in case the file can
not be stat'ed.
This fixes bug #1737
We fetch the id from the server, but don't save them in the database.
I Could have used INSTRUCTION_UPDATED for that, but then i would need to update the
reconcile algorithm to take in account the fact that UPDATED is possible there.
Instead, use should_update_etag which means the db is going to be written again
Remove reference to old instruction _UPDATED and _DELETED which does not make sens with
the new propagator
Improve the test to test this case, and that etags are properly writen to the DB
when there is a fake conflict
