webdav: deal with buggy webdav servers in renameExport

box.com already had a special case, since its renaming was known buggy.
In its case, renaming to the temp file succeeds, but then renaming the temp
file to final destination fails.

Then this 4shared server has buggy handling of renames across directories.
While already worked around with for the temp files when storing exports
now being in the same directory as the final filename, that also affected
renameExport when the file moves between directories.

I'm not entirely clear what happens on the 4shared server when it fails
this way. It kind of looks like it may rename the file to destination and
then still fail.

To handle both, when rename fails, delete both the source and the
destination, and fall back to uploading the content again. In the box.com
case, the temp file is the source, and deleting it makes sure the temp file
gets cleaned up. In the 4shared case, the file may have been renamed to the
destination and so cleaning that up avoids any interference with the
re-upload to the destination.

doc/bugs/WEBDAV_export_has_wrong_subdirectory_content.mdwn

@@ -55,3 +55,4 @@ Thx!
 
 [[!tag projects/datalad]]
 
+> [[fixed|done]] --[[Joey]]

doc/bugs/WEBDAV_export_has_wrong_subdirectory_content/comment_11_03ea7014854be4fa9f40a8815616b81d._comment

@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2021-03-22T16:27:10Z"
+ content="""
+Ok, failed kind of like I expected, although I have to say the filenames
+don't entirely make sense to me.
+("git-annex-webdav-tmp" is not used in filenames when renaming an exported
+file, only when storing it in the first place)
+
+So what seems to make sense for git-annex to do when renaming an exported
+file is: Try to rename, and if it fails, delete the source and the
+destination -- since it has no idea what may have been left in either place
+-- and then fall back to uploading the file again instead. I have
+implemented that.
+"""]]