Migrate dns data sources back to the SDK to solve auth issue resulting from migration to plugin framework

[modular-magician]

Description

Hopefully will fix hashicorp/terraform-provider-google#16832

What this PR does

This PR returns these data sources back to being implemented with the SDK:

• google_dns_keys
• google_dns_managed_zone
• google_record_set

The PR also migrates google_dns_managed_zones to the SDK. It was originally implemented in the plugin framework.

When resources were migrated to the PF from SDK there were some small schema changes, namely adding id fields to schemas. These changes have been implemented in the new SDK code for the data sources, even though the original SDK code didn't contain them.

Why this PR is happening

tl;dr of the timeline leading to this PR:

• Early 2023
  • The provider was muxed and resulted in a number of customer issues, which were not caught by acceptance tests.
  • Acceptance tests for identified issues were subsequently added
  • Important detail is that the SDK and PF sides of the provider contain parallel implementations of provider configuration logic
• Spring 2023
  • It's identified that migrated data sources fail acceptance tests in VCR
  • Exact details why aren't relevant to this PR
• Jan 2024
  • I have a customer issue with a deadline to implement a plural version of the google_dns_managed_zone data source. I implement it in plugin-framework with the rationale that I'm about to start digging into the previous migration work and working through issues such as VCR test problem, so adding one more problematic data source is OK (spoiler: I was wrong).
  • I'm alerted to an issue opened in Dec 2023 that indicates there are auth issues specific to the dns data sources and not the dns resources, i.e specific to the plugin-framework migrated parts of that service.

I believe the issue data.google_dns_managed_zone always fails with "Post "https://oauth2.googleapis.com/token": context canceled" shows there are problems with the provider configuration code implemented in the plugin-framework side of the provider. All our acceptance tests auth the provider in one way, so this bug wasn't identified until the first issue was opened.

Given that tweaking how the plugin-framework provider is authenticated is a non-trivial task, and that I will also need to make large changes to the central provider configuration code to address the VCR issue, I decided that the best way to resolve the problem for users is to revert the changes to the dns data sources and for me to do this work 'in my own time'.

Testing

I've manually tested and also have some acc tests but they're highly dependent on the machine running them.

Next steps

In future I'll fully investigate the auth issues in the plugin-framework implementation of the provider configuration logic. I suspect I'll need to make wider changes in that code to avoid having 2 parallel implementations, so I chose to do that work separately to addressing the issue linked to this this PR.

Relevant issues and PRs

• data.google_dns_managed_zone always fails with "Post "https://oauth2.googleapis.com/token": context canceled" hashicorp/terraform-provider-google#16832
• VCR test(s) fail during replay: Framework converted resources hashicorp/terraform-provider-google#14158
• Add google_dns_managed_zones data source and acceptance test magic-modules#9742

---

Release Note Template for Downstream PRs (will be copied)

dns: fixed bug where some methods of authentication didn't work when using `dns` data sources

Derived from GoogleCloudPlatform/magic-modules#10368

[conventional-commit-lint-gcf]

🤖 I detect that the PR title and the commit message differ and there's only one commit. To use the PR title for the commit history, you can use Github's automerge feature with squashing, or use automerge label. Good luck human!

-- conventional-commit-lint bot
https://conventionalcommits.org/