Terraform AWS provider 6.73.0: breaking changes

Breaking changes listed in the release notes:

• aws_wafv2_web_acl_rule: Removes and_statement from statement blocks nested in and_statement, and or_statement from statement blocks nested in or_statement. These values are rejected by AWS.
• aws_wafv2_web_acl_rule: Removes managed_rule_group_statement, rate_based_statement and rule_group_reference_statement from statement blocks nested in and_statement, not_statement and or_statement. These values are rejected by AWS.
• aws_wafv2_web_acl_rule: Removes or_statement from statement blocks nested in or_statement. These values are rejected by AWS.

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.73.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.