fix google_bigquery_table encryption_configuration modifications

[MartinNowak]

• changing to/from CMEK requires recreating the table (see Change a table from default encryption to Cloud KMS protection)
• the BQ API appears to support the default -> kms transition (no API error), but tables don't appear to get encrypted according to the UI/CLI
• see Fix google_bigquery_table encryption_configuration modifications hashicorp/terraform-provider-google#5241 and add encryption_configuration to google_bigquery_table resource #2763 (comment) for more info

Release Note Template for Downstream PRs (will be copied)

[modular-magician]

Hello! I am a robot who works on Magic Modules PRs.

I have detected that you are a community contributor, so your PR will be assigned to someone with a commit-bit on this repo for initial review. They will authorize it to run through our CI pipeline, which will generate downstream PRs.

Thanks for your contribution! A human will be with you soon.

@rambleraptor, please review this PR or find an appropriate assignee.

[slevenick]

I'm not sure I'm convinced this is the best way to go here. I believe that technically this is the correct way to represent this in Terraform, because forcing a recreate is the only way to handle changes to encryption via the API.

What worries me is that we would be introducing a potentially dangerous data loss situation when someone attempts to add encryption to their bigquery table, losing any data that existed in the table.

I would almost prefer throwing an error when attempting to update the encryption config and point to the guide on copying & encrypting a table, but that's not very terraform-y

@emilymye thoughts?

[emilymye]

I don't mind the more restrictive "encryption cannot be updated" approach for now, would be down with a customdiff.ValidateChange - if enough users hate it, we can switch to just allow ForceNew encryption. It doesn't hurt anyone who decided to do the more tedious copy-encryption, and I don't think anyone is updating their table encryption in an automated workflow.

[nat-henderson]

We discussed this in a meeting and prefer the ForceNew approach for symmetry with our other data storage resources. This PR LGTM.

[modular-magician]

Hi! I'm the modular magician, I work on Magic Modules.
I see that this PR has already had some downstream PRs generated. Any open downstreams are already updated to your most recent commit, 75262f5.

Pull request statuses

No diff detected in terraform-google-conversion.
No diff detected in Ansible.
No diff detected in Inspec.

New Pull Requests

I built this PR into one or more new PRs on other repositories, and when those are closed, this PR will also be merged and closed.
depends: hashicorp/terraform-provider-google-beta#1591
depends: hashicorp/terraform-provider-google#5321

[MartinNowak]

Thanks for the thoughtful consideration, I agree with the consistency argument.
Data loss is indeed something to carefully watch out for with Terraform though. Some policy/config that prevents destruction of (certain) resources seems like a proper way to handle this. Maybe with a simpler approach than https://www.terraform.io/docs/cloud/sentinel/sentinel-tf-012.html though.