Comment 9 for bug 2025277

This sounds like the bug fix wasn't properly done, because it didn't take into consideration that we have rolling upgrade support and we can have a service send the RPC request with the old parameter count.

In the backup service we can see the rpc call checks that the RPC version being used is 2.4 and only then sends the `volume_is_new` parameter:
```
    def restore_backup(self, ctxt, backup_host, backup, volume_id,
                       volume_is_new):
        LOG.debug("restore_backup in rpcapi backup_id %s", backup.id)
        cctxt = self._get_cctxt(server=backup_host)
        if self.client.can_send_version('2.4'):
            cctxt.cast(ctxt, 'restore_backup', backup=backup,
                       volume_id=volume_id, volume_is_new=volume_is_new)
        else:
            cctxt.cast(ctxt, 'restore_backup', backup=backup,
                       volume_id=volume_id)
```

But just because the cinder-volume service hasn't started in that RPC version it doesn't mean it doesn't have the new code, because it can be running in compatibility mode as part of a rolling upgrade or because we have stale backup service entries in the DB, or because the upgrade process wasn't done right.

What we need to do is set a reasonable default for `volume_is_new` on the backup manager so that it can behave like it did before 2.4.