Undescriptive duplicity/collection-status error when the backup directory contains two volumes with different file names and same volume number in the same backup set (lp:#1652410)

[Original report](https://bugs.launchpad.net/bugs/1652410) created by **Naël (nathanael-naeri)**
```
[System]

Ubuntu 16.04
deja-dup 34.2-0ubuntu1.1
duplicity 0.7.06-2ubuntu2

[Symptoms]

When the backup location unfortunately contains two backup volumes with
different file names and same volume number in the same backup set, for
instance:

  duplicity-full.20161129T015237Z.vol1.difftar
  duplicity-full.20161129T015237Z.vol1.difftar.gz

this confuses duplicity collection-status, which ends up returning an
undescriptive Python assertion error, as seen in this Déjà-Dup log file:

  DUPLICITY: INFO 1
  DUPLICITY: . Args: /usr/bin/duplicity collection-status [...]

  [...]

  DUPLICITY: DEBUG 1
  DUPLICITY: . 12 files exist on backend

  DUPLICITY: DEBUG 1
  DUPLICITY: . Extracting backup chains from list of files:
   [u'duplicity-full.20161129T015237Z.vol1.difftar',
    u'duplicity-full.20161129T015237Z.manifest',
    u'duplicity-full.20161129T015237Z.vol1.difftar.gz',
    u'duplicity-full-signatures.20161129T015237Z.sigtar.gz',
    u'duplicity-full-signatures.20161129T015237Z.sigtar',
    [...]

  DUPLICITY: DEBUG 1
  DUPLICITY: . File duplicity-full.20161129T015237Z.vol1.difftar is not
    part of a known set; creating new set

  DUPLICITY: DEBUG 1
  DUPLICITY: . File duplicity-full.20161129T015237Z.manifest is part of
    known set

  DUPLICITY: ERROR 30 AssertionError
  [...]
  DUPLICITY: . File "/usr/lib/python2.7/dist-
packages/duplicity/collections.
    py", line 105, in add_filename(self.volume_name_dict, filename)
  DUPLICITY: . AssertionError:
    ({1: 'duplicity-full.20161129T015237Z.vol1.difftar'},
    'duplicity-full.20161129T015237Z.vol1.difftar.gz')

What happens is that duplicity collection-status takes the uncompressed
duplicity-full.20161129T015237Z.vol1.difftar for the start of a backup set,
then tries to add the compressed duplicity-
full.20161129T015237Z.vol1.difftar.gz to this set, and fails because the
volume number of this file has already been added to the set. Otherwise
there would be two backup volumes with the same volume number in the backup
set.

Note that a similar issue may also happen for file signatures instead of
backup volumes, e.g.:

  duplicity-full-signatures.20161129T015237Z.sigtar
  duplicity-full-signatures.20161129T015237Z.sigtar.gz

but backup volumes appear to be tripped on first, perhaps because of
alphabetic order.

Note also that under normal operation, the backup location isn't supposed
to contain a mixed of compressed and uncompressed files (or encrypted and
unencrypted files), but this situation was still reported by the bug
reporter in the original bug report.

[Test case]

See comment 19, written for Déjà-Dup, but easily adaptable to pure
duplicity I think.

[Ideas for fixing]

Duplicity already has checks to avoid considering files whose names don't
look like they could be part of a backup set (see comment 19, point 4).
Perhaps this filename filter could be improved on so that duplicity doesn't
burp so hard when a backup volume is present in both compressed and
uncompressed forms? Perhaps it could have duplicity prefer a particular
filename when there are two volumes with the same number in the same backup
set? But then which one and on what grounds?

Please also see comment 23.

[Easier fix]

Worst case, if this situation can't be handled automatically and the
situation requires a human to examine the contents of the backup repository
to take adequate action, then it would be helpful that duplicity return a
more descriptive message than the current terse assertion error.
```
Original tags: apport-bug testcase xenial

Story points: 28.0