Terraform AWS provider 6.68.0: breaking changes

Breaking changes listed in the release notes:

• aws_docdb_cluster: availability_zones now validates that at most 3 items are provided at plan time. This is acceptable in a minor version because AWS would always reject requests with more than 3 availability zones at apply time.
• aws_rds_cluster: availability_zones now validates that at most 3 items are provided at plan time. This is acceptable in a minor version because AWS would always reject requests with more than 3 availability zones at apply time.

1. Give the provider a version constraint in the required_providers block. HashiCorp recommends a version constraint for every provider a module depends on.
2. In a root module, also specify the maximum provider version, to avoid accidental upgrades to incompatible new versions. The ~> operator is a shorthand that allows the rightmost component of a version to increment. Do not use ~> or other maximum-version constraints in modules you intend to reuse across many configurations. Specify a minimum version there and let the root module manage the maximum version.
3. Commit the dependency lock file to version control with the configuration, so that Terraform always installs the same provider versions.
4. To adopt 6.68.0, change the version in the required_providers block and re-run terraform init. HashiCorp states that this upgrades the provider version in the lock file. Without a change, Terraform re-selects the version recorded in the lock file, even if a newer version has become available. With the -upgrade option, terraform init disregards the recorded selection and selects the newest available version matching the version constraint. The release notes list each breaking change.
5. Review the changes Terraform made to the lock file in version control. If they are changes you made intentionally, send them through the usual code review process.