Allow in place Subnet Secondary IP ranges updates

[averbuks]

The Problem

The Google Cloud Compute API for Subnetworks imposes a restriction: secondary IP ranges cannot be added and deleted within the same patch or update request. Currently, this limitation prevents Terraform from performing:

• In-place updates: Modifying an existing range (which Terraform treats as a delete + add).
• Mixed changes: Adding one range while deleting another in a single terraform apply.

The Solution

This PR introduces logic to the google_compute_subnetwork resource to sequence the API operations. It ensures that any pending deletions of secondary IP ranges are processed and committed before the API call for additions is initiated.

By decoupling these operations into a sequential workflow, we bypass the API's "single-call" constraint and allow for more complex subnet modifications without manual intervention or multi-stage applies.

Fixes hashicorp/terraform-provider-google#2570

compute: allow in-place updates to the `secondary_ip_range` field for resource `google_compute_subnetwork`

[github-actions]

Googlers: For automatic test runs see go/terraform-auto-test-runs.

@slevenick, a repository maintainer, has been assigned to review your changes. If you have not received review feedback within 2 business days, please leave a comment on this PR asking them to take a look.

You can help make sure that review is quick by doing a self-review and by running impacted tests locally.

[modular-magician]

Hi there, I'm the Modular magician. I've detected the following information about your changes:

Diff report

Your PR generated some diffs in downstreams - here they are.

google provider: Diff ( 2 files changed, 181 insertions(+), 68 deletions(-))
google-beta provider: Diff ( 2 files changed, 181 insertions(+), 68 deletions(-))

[modular-magician]

Tests analytics

Total tests: 1398
Passed tests: 1307
Skipped tests: 90
Affected tests: 1

Click here to see the affected service packages

• compute

Action taken

Found 1 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests

• TestAccComputeSubnetwork_secondaryIpRanges

Get to know how VCR tests work

[modular-magician]

🟢 Tests passed during RECORDING mode:
TestAccComputeSubnetwork_secondaryIpRanges [Debug log]

🟢 No issues found for passed tests after REPLAYING rerun.

---

🟢 All tests passed!

View the build log or the debug log for each test

[zli82016]

LGTM. @slevenick, would you like to give it a secondary round of review (this issue is really old)? Thanks.