v5.36.0 plans replacement of existing upcloud_managed_database_mysql due to lower_case_table_names

[ximpanz]

After upgrading UpCloudLtd/upcloud from v5.35.0 to v5.36.0, an unchanged existing upcloud_managed_database_mysql
resource is planned for replacement.

We do not configure lower_case_table_names, but the plan now shows:

# upcloud_managed_database_mysql.redacted_mysql must be replaced
properties {
  + lower_case_table_names = (known after apply) # forces replacement
}

That looks wrong for an existing service that was already created before the provider upgrade.

Minimal config shape:

resource "upcloud_managed_database_mysql" "redacted_mysql" {
  name  = "redacted-mysql"
  title = "redacted-mysql"
  plan  = "2x2xCPU-4GB-50GB"
  zone  = "se-sto1"

  properties {
    sql_mode           =
"ANSI,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,STRICT_ALL_TABLES"
    wait_timeout       = 300
    sort_buffer_size   = 4000000
    max_allowed_packet = 16000000
    default_time_zone  = "Europe/Stockholm"
    admin_username     = "admin"
    admin_password     = "REDACTED"
    public_access      = true
    ip_filter          = ["REDACTED/32", "REDACTED/24"]
  }
}

Expected:

- provider upgrade should not plan replacement when lower_case_table_names is not configured and the DB is unchanged

Actual:

- MySQL DB is planned for replacement because lower_case_table_names becomes unknown and is treated as a ForceNew field
  during plan

There is also broader churn on other managed database resources after the same upgrade.

For existing PostgreSQL services, the provider now plans large in-place updates where many existing properties become known
after apply during refresh/plan, even though the Terraform configuration is unchanged. A new property such as
public_access_prometheus = false also appears in the plan. The PostgreSQL services are not replaced, but the diff is much
larger than expected for a provider-only upgrade.

For existing Valkey services, the same pattern appears: a large in-place diff, new surfaced properties, and many values
turning into known after apply without any intended configuration change. In our case, this also causes downstream
dependent resources to become dirty in the same plan.

So the main problem is:

- MySQL replacement is unsafe and unexpected
- PostgreSQL and Valkey also appear to have refresh/schema instability in v5.36.0

OpenTofu/Terraform plan output is available if needed.

[villevsv-upcloud]

Hi, thank you for the bug report.

We identified a fix for the lower_case_table_names issue and fixed that in the v5.36.2 release.

We will look into the additional issue of database properties generally causing a dirty state.