Cleanup with Paramiko backend does not remove files due to missing filename byte decoding

Duplicity Version: 0.8.12;
Python Version: 3.8.3;
OS Distro and version: Arch Linux 2020-07-15;
Target filesystem: Linux (Ubuntu 18.04.4 LTS) via scp (paramiko)

Log output does not reveal underlying issue.

When running duplicity --cleanup --force scp://user@host//path/to/backup, files to be removed are not actually removed.

Further investigation revealed the path used by SSHParamikoBackend._delete() (at ssh_paramiko_backend.py:391 as of commit 4d4b1673) gets interpolated as follows:

    rm '/path/to/backup/b'duplicity-inc.20200702T140004Z.to.20200709T140014Z.vol1.difftar.gpg''
    rm '/path/to/backup/b'duplicity-inc.20200702T140004Z.to.20200709T140014Z.vol2.difftar.gpg''
    rm '/path/to/backup/b'duplicity-inc.20200702T140004Z.to.20200709T140014Z.vol3.difftar.gpg''

The cause of this is that the 'filename' parameter to _delete() is a byte object.

The implementations for _put() and _get() in the same backend convert the remote filename to a string as follows:

    def _get(self, remote_filename, local_path):
        # remote_filename is a byte object, not str or unicode
        remote_filename = remote_filename.decode(u"utf-8")

Note: other backends use the duplicity.util.fsdecode function, which seems like it should be the preferred decoding method.

Proposed solution (see attached git patch file):

1. Replace remote filename decoding in other SSHParamikoBackend methods with util.fsdecode()

2. Add 'filename = util.fsdecode(filename)' as the first line of SSHParamikoBackend._delete() to parallel the treatment of remote filenames in other methods.