Fix update retention logic

[markdboyd]

Changes proposed in this pull request:

Fixes https://github.com/cloud-gov/private/issues/2052

A previous broker bug that has since been fixed allowed updated databases to have a backup retention period of 0, which disables automated backups on RDS databases. Even though that bug has been fixed, there are some brokered databases which have backup_retention_period: 0 stored in the broker's database, and the current broker logic allows that value to get re-applied to the RDS database on every update, thus re-disabling automated backups.

This PR fixes two bugs:

• Users should not be able specify 0 as a retention period, or really any value less than the configured minimum retention period (default: 14)
• When updating existing instances, if they have a value of 0 for the backup retention period, then they should default to the minimum retention period

Things to check

• For any logging statements, is there any chance that they could be logging sensitive data?
• Are log statements using a logging library with a logging level set? Setting a logging level means that log statements "below" that level will not be written to the output. For example, if the logging level is set to INFO and debugging statements are written with log.debug or similar, then they won't be written to the otput, which can prevent unintentional leaks of sensitive data.

Security considerations

Our website states that automated backups are enabled and retained for 14 days on all brokered databases. Furthermore, if automated backups are disabled and there is a data loss scenario, then we as a platform may not be able to restore a customer's data.

[JasonTheMain]

Looks like a good fix