gke node pool: add 404 response code check on delete call

[roycaihw]

If this PR is for Terraform, I acknowledge that I have:

• Searched through the issue tracker for an open issue that this either resolves or contributes to, commented on it to claim it, and written "fixes {url}" or "part of {url}" in this PR description. If there were no relevant open issues, I opened one and commented that I would like to work on it (not necessary for very small changes).
• Generated Terraform, and ran make test and make lint to ensure it passes unit and linter tests.
• Ensured that all new fields I added that can be set by a user appear in at least one example (for generated resources) or third_party test (for handwritten resources or update tests).
• Ran relevant acceptance tests (If the acceptance tests do not yet pass or you are unable to run them, please let your reviewer know).
• Read the Release Notes Guide before writing my release note below.

Release Note Template for Downstream PRs (will be copied)

container: fixed container node pool not removed from the state when received 404 error on delete call for the resource `google_container_node_pool`

Similar to #4512. Reproduced the bug and verified the fix worked locally: cl/371048390, b/186679604

fixes hashicorp/terraform-provider-google#9023

cc @rileykarson

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

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

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

[modular-magician]

Hi! I'm the modular magician. Your PR generated some diffs in downstreams - here they are.

Diff report:

Terraform GA: Diff ( 1 file changed, 4 insertions(+))
Terraform Beta: Diff ( 1 file changed, 4 insertions(+))

[modular-magician]

I have triggered VCR tests based on this PR's diffs. See the results here: "https://ci-oss.hashicorp.engineering/viewQueued.html?itemId=184892"

[roycaihw]

I noticed that I made a mistake when sending this PR.

cl/371172872 was correct, but when I sent this OSS PR, the change was already made in OSS (just a few lines below). Since the code change in this PR wasn't what I intended to make, we may just revert this PR.

On the other hand, different from cl/371172872. This OSS code had an extra containerClusterAwaitRestingState before containerNodePoolAwaitRestingState. I wonder if we would introduce a similar bug if we simply revert this PR-- when deleting a node pool, should we raise an error if the cluster doesn't exist, or should we just print a log? If it's the latter, then we may fix this log message.

@rileykarson @ScottSuarez WDYT?

[rileykarson]

If the cluster doesn't exist we can assume the node pool doesn't. It's not immediately obvious what's wrong here to me.

[roycaihw]

sounds good. Maybe I shouldn't say "fix this log message". Since we assume the node pool doesn't exist because the cluster doesn't, we can improve this log message to "[INFO] GKE cluster %s doesn't exist, skipping node pool %s deletion", nodePoolInfo.cluster, d.Id().

It's not that critical, just the code wasn't doing what I thought it would do, and I think maybe it would be confusing to others as well.

[rileykarson]

Good point, we could make it more clear! If you're interested in changing it feel free, but I don't feel it's required.

[roycaihw]

will do. Thanks