Fail backup if it already exists in object storage

[carlisia]

In lieu of #629

Fixes #623

Notes:

• The test below "as is" was left out of this version. The intention of testing for failures in the case of a backup already existing was incorporated in other existing (current) tests: https://github.com/heptio/velero/pull/629/files#diff-d0a3ff018929aec3abbaa4c8a2c299ccR148

• This commit was in the original PR, but I don't think we want it? d1cd91d

• WIP: working on testing these against the main SCPs.

[skriss]

initial review. I can sign up for Azure testing since I have a cluster up and running

[skriss]

Two small comments, otherwise LGTM. Please add a changelog file as well!

[skriss]

code LGTM, just waiting on testing

[skriss]

After locally fixing the first comment from above, I was able to confirm that on Azure, backups correctly fail if there's already a backups/<backup-name>/velero-backup.json in object storage, and if that's not the case, they proceed.

[carlisia]

Sweet!!! @ncdc did great work!

[skriss]

An observation: in the case that this code is intended to catch, we end up with a Failed backup in-cluster. So, now, if I velero backup delete this backup -- the files in object storage get deleted. However, this almost certainly wasn't my intent, since those files in object storage weren't created by this backup I just created.

I'm guessing that to fix this, we'll need to add velero-managed UIDs to backups, so that we have a unique ID for each backup across time and space that we can use to determine if two items are the same or not. I don't think it's in scope for this PR, but we should follow up on it. It's somewhat related to #629 (comment).

[skriss]

LGTM

[nrb]

The UID fix seems reasonable to me. I briefly wondered if it would then be better to use those identifiers on the object storage vs the user-provided name, as that would remove the need for this code. However, that's too invasive a change at this stage, so I'm for just attaching it and using it on sync comparison.