Add 'soft_delete_policy' to 'google_storage_bucket' resource

[zli82016]

Part of b/346407424

Backport of GoogleCloudPlatform/magic-modules#10171 in provider 5.22 based on the impact to customers of the new soft delete defaults, this will allow them to opt out.

1. Cherry-picked the change to add 'soft_delete_policy' to 'google_storage_bucket' resource
2. Upgrade go api client to the version that SoftDeletePolicy field is present
3. Fixed other failed tests

Tests run on Teamcity:
storage, fwtransport, firebase

[github-actions]

** WARNING **: This repository is generated by https://github.com/GoogleCloudPlatform/magic-modules. Any changes made directly to this repository will likely be overwritten. If you have further questions, please feel free to ping your reviewer or, internal employees, reach out to one of the engineers. Thank you!

[rileykarson]

Just commenting on branch mechanics prior to review. I've confirmed release-4.85.0 branch is branched from the same commit as the v4.84.0 tag right now, and this PR will update both the changelog + code of the branch to what we intend to release.

(dupe of hashicorp/terraform-provider-google#18395 (comment))

[zli82016]

I run the tests in Teamcity for the affected services. If we prefer run test for the whole provider, feel free to let me know.

[zli82016]

Release 4.85.0 is based on 4.84.0 and no diffs

[rileykarson]

LGTM, let's get explicit approval from @SarahFrench before merging

After that we should kick off a full test run on the release branch, and ensure we release this when Sarah or a delegate is available in case anything goes wrong with the release tooling (probably tomorrow morning, but we'll work that out offline in chat)

[SarahFrench]

👋 Hey, I'm concerned about the "After that we should kick off a full test run on the release branch"

There isn't currently a good way to trigger the entire test suite. In the UI this would mean clicking through to trigger a custom build using a non-default branch in each service's build configuration. Is this limitation known about?

It could be possible to speed this up with a short script though, as custom builds can be triggered using the TeamCity API: https://www.jetbrains.com/help/teamcity/rest/start-and-cancel-builds.html#Start+Regular+Build

[zli82016]

There isn't currently a good way to trigger the entire test suite. In the UI this would mean clicking through to trigger a custom build using a non-default branch in each service's build configuration. Is this limitation known about?

Thank you for the information. I didn't realize the limitation. If we want to trigger all of the tests as we did for feature branch or the branch for functions, should we change the code in magic module?

[SarahFrench]

Are you asking if we need to make a change to the TeamCity configuration to help test the release-4.85.0 branch?

In the past we changed the TeamCity configuration so that we could test a 5.0.0 feature branch one night of the week, and all other nights we tested off main. For a long-lived feature branch I'd agree that's a good approach, but for a single test suite run of a release branch it feels a little heavy handed

[SarahFrench]

Pivoting to internal chat for discussion

[rileykarson]

Not aware of the limitation. If this'd be easy enough (something like <3 hours of manual effort) we may want to do a full run- I'll leave that decision up to the two of you- but I'd like to test a representative set of handwritten services given the client upgrade. GCS is already tested, so if we did compute + GKE + resourcemanager as well that'd be enough for me personally.