Ensure max backup bug

[alynlin]

When etcd max revision reaches the next order of magnitude, the deleted expired file is the latest backup file.

[mdkrajewski]

@alynlin I'm seeing behavior where the backup being deleted to ensure a maximum number of backups isn't necessarily the oldest backup, resulting in the latest backup possibly being deleted instead, and leaving around much older backups. Is this what you are describing?

I see in backup_manager.go's EnsureMaxBackup() that it is sorting based on file name, which is not reliable for this purpose, as the etcd max kv store revision number is inserted before the date.

For my local build, I will try changing this line in backup_manager.go, to put rev at the end of s3Path, and probably submit a PR:

s3Path = fmt.Sprintf(s3Path+"_v%d_%s", rev, now.Format("2006-01-02-15:04:05"))

[mdkrajewski]

On second thought, I'm going to try submitting a solution that fixes the sorting instead of changing the format of the backup paths, to make the fix backwards-compatible with current deployments.

[mdkrajewski]

@alynlin I've submitted a PR (#2116). Let me know what you think! :)