feat(cloudsql-instance): expose retain_backups_on_delete

[piotr-tokaj]

What

Exposes the settings.retain_backups_on_delete attribute on google_sql_database_instance as a new field on the existing backup_configuration module variable:

variable "backup_configuration" {
  type = object({
    # ... existing fields ...
    retention_count          = optional(number, 7)
    retain_backups_on_delete = optional(bool, true)
  })
  default = {
    # ... existing fields ...
    retention_count          = 7
    retain_backups_on_delete = true
  }
}

and wires it into the settings {} block of both google_sql_database_instance.primary and google_sql_database_instance.replicas.

Why

When a Cloud SQL instance is deleted, this flag controls whether its automated and on-demand backups are kept afterwards. There is no way to set it through the module today, so users who want the non-default behaviour (drop backups on delete, e.g. for short-lived preview / PR environments) have to either delete the backups manually from the console / API after destroy, or fork the module.

It belongs on backup_configuration rather than as a sibling top-level variable: every other knob that decides what happens to backups (enabled, point_in_time_recovery_enabled, retention_count, log_retention_days, …) already lives there, so users only have one place to look when they're reasoning about backup behaviour. Keeping it next to retention_count in particular makes the relationship between "how many backups we keep while the instance is alive" and "what happens to those backups when the instance is destroyed" obvious.

Compatibility

• New field is optional with default = true, which matches the current GCP default and what Terraform gets today when the attribute isn't set by the module. Existing callers see no planned diff.
• Applied to both primary and replicas so their retention behaviour stays consistent by default; opting out (false) flips both in one place, which is almost always what users want.
• The README was regenerated with tools/tfdoc.py; this also removes a stale "Fixtures" entry that referenced a non-existent fixture file (unrelated cleanup, surfaced by re-running the doc generator).

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[Calvin-Cheng1]

Would prefer to handle this logic on the already existing variable: "backup_configuration" there is a strong reason not to

[piotr-tokaj]

Would prefer to handle this logic on the already existing variable: "backup_configuration" there is a strong reason not to

Great idea! I did that, and updated the Readme too

[Calvin-Cheng1]

LGTM