Remove existing path before restoring a symlink

[jkmw]

Bugfix: Make sure that symlinks can be created during recovery

When restoring a symlink, restic reported an error if the target path already existed.
With this change, the potentially existing target path is first removed before the symlink is recreated.

#2578

What does this PR change? What problem does it solve?

At the moment restic overwrites existing data in the restore target, unless it is a symlink, in which case an error is thrown.

From my point of view, restic should behave with symlinks in the same way as with all other file types and "overwrite" already existing paths.

This change causes restic to "overwrite" existing data (by delete and create) even if a symlink is to be restored.

See #2578 for more details.

Was the change previously discussed in an issue or on the forum?

Closes #2578

Checklist

• [ x ] I have enabled maintainer edits.
• [ x ] I'm done! This pull request is ready for review.

[MichaelEischer]

Also please add a short changelog entry using the template at https://github.com/restic/restic/blob/master/changelog/TEMPLATE

[MichaelEischer]

I guess I haven't been explicitly enough in my previous comment: replacing os.RemoveAll with os.Remove was not a suggestion, but rather a request. The other parts of the restorer do not wipe out entire directory trees if these are standing in the way, thus restoring a symlink must behave just the same.

[MichaelEischer]

LGTM. Thanks!