Improve the backup schedule cron job so that only one backup runs at a time.

[calind]

1. Controller should not rely on an internal lock, but rather check if there's an active job
   https://github.com/presslabs/mysql-operator/blob/e0ef8bb900001a91db4aa0e78596a8f8a0bf9d12/pkg/controller/clustercontroller/backups.go#L101-L102
2. In case of an active job, we should create an automated backup, but mark it as failed, with the reason that another backup is running

[cu12]

@calind I concur, I recently saw some weird issues due to this

I had a cluster down, but the operator kept starting the new backup jobs and that resulted in two errors in our environment which I believe are connected to this.

1. We ran into sshd.socket stops working after a while coreos/bugs#2181 on nodes, where these pods were scheduled (gazillion pods every second)
2. Apps that were talking to php-fpm on these nodes were stuck after some time

It's a long shot, but either some back-off and/or mechanism to defer the backup job when cluster is not in ready state would be nice

[HBO2]

@calind I totally agree with @cu12. It takes a while to have the cluster up and running and I had to some big issues with a multitude of failing pods based on the backup jobs.

And also when the S3 is nog configures correctly for some reason, you will get an immense amount of pods.

thx