Restore file from trashbin to a different place overwriting a file

Steps to reproduce

  Scenario Outline: restoring a file to an already existing path overrides the file
    Given using <dav-path> DAV path
    And user "user0" has been created with default attributes and skeleton files
    And user "user0" has uploaded file with content "file to delete" to "/textfile0.txt"
    And user "user0" has uploaded file with content "PARENT textfile0 content" to "/PARENT/textfile0.txt"
    And user "user0" has deleted file "/textfile0.txt"
    When user "user0" restores the file with original path "/textfile0.txt" to "/PARENT/textfile0.txt" using the trashbin API
    Then the HTTP status code should be "204"
    # Sometimes "/PARENT/textfile0.txt" is found in the trashbin. Should it? Or not?
    # That seems to be what happens when the restore-overwrite happens properly,
    # The original /PARENT/textfile0.txt seems to be "deleted" and so goes to the trashbin
    #And as "user0" the file with original path "/PARENT/textfile0.txt" should not exist in trash
    And as "user0" file "/PARENT/textfile0.txt" should exist
    # sometimes the restore from trashbin does overwrite the existing file, but sometimes it does not. That is also surprising.
    # the current observed behavior is that if the original /PARENT/textfile0.txt ended up in the trashbin,
    # then the new /PARENT/textfile0.txt has the "file to delete" content.
    # otherwise /PARENT/textfile0.txt has its old content
    And the content of file "/PARENT/textfile0.txt" for user "user0" if the file is also in the trashbin should be "file to delete" otherwise "PARENT textfile0 content"
    #And the content of file "/PARENT/textfile0.txt" for user "user0" should be "file to delete"
    Examples:
      | dav-path |
      | old      |
      | new      |

Expected behaviour

Maybe:

1. the restored file should just overwrite the existing file, and the existing file is gone (or is saved as an old version if files_versions is enabled), or;
2. The restored file has (2) on the end of its name, and the existing file stays, or;
3. ???

Actual behaviour

Sometimes the restore from trashbin overwrites the existing file. When that happens, the existing file is found in the trashbin. I guess that the code-path deletes the existing file (triggering an event that causes it to be saved into the trashbin). And the restored file has the correctly-restored content.

But also sometimes the existing file is not found in the trashbin, and has not been overwritten (it still has the old content). But the API call to restore from trashbin still returns 204 success.

Server configuration

Local runs of the above scenario in a development environment on top of current master
And in drone CI it happens also.

Start with the trashbin API restore flow and the DAV scenario in this issue, comparing behavior for the old and new DAV paths. Reproduce the case locally and in the Drone CI scenario, then establish which overwrite behavior is intended and make the outcome deterministic. Done means the selected behavior is consistently returned with the correct file content and trashbin state.