fix(secretstores.googlecloud): Handle public GCP service account keys correctly

[crflanigan]

Summary

When using a normal GCP service-account key (the JSON downloaded from the Cloud Console, type: "service_account") with the new secret store

• token = "@{id:token}" pattern in outputs.stackdriver, the Google auth library previously received an unscoped token that was rejected by the Monitoring API.

This change adds a tiny guarded default in Init():

• If credType == "service_account" and no scopes are explicitly set, automatically use ["https://www.googleapis.com/auth/monitoring"].

The existing GDCH/STS flow (via sts_audience) is completely untouched. The new credential_scopes config option is also available for users who need a different set (e.g. cloud-platform).

No changes to stackdriver.go or any other plugin — keeps the PR as small and low-risk as possible

Checklist

• No AI generated code was used in this PR
• AI generated code used in this PR follows the InfluxData Policy on AI-Generated Code Contributions

Related issues

resolves #16326

[srebhan]

Thanks a lot @crflanigan! Just a small comment... Please run make docs before pushing. :-)

[crflanigan]

@srebhan, I committed your suggestion :)

As for the make docs, do I need to do that now, or with this committed suggestion (thanks!) are we good to go?

[srebhan]

@crflanigan you need to do it now and push the changes as CI checks if the README "configuration" section matches the sample.conf... :-)

[crflanigan]

Alright, all done @srebhan!

[srebhan]

Thanks @crflanigan!

[skartikey]

The auto-default to https://www.googleapis.com/auth/monitoring for service_account keys couples this generic secret store to one specific consumer (Stackdriver). The same store can hand tokens to outputs.cloud_pubsub, BigQuery sinks, etc., and those users will hit the same 403 you're fixing here, just with a different surface.

Two cleaner options:

1. Broaden the default to cloud-platform - https://www.googleapis.com/auth/cloud-platform covers virtually every GCP API and is the standard "works for any service" scope. The Stackdriver flow keeps working, and so do Pub/Sub, BigQuery, etc.
2. Drop the auto-default entirely and return an error in Init() when credType requires scopes and credential_scopes is empty, with a message pointing the user at the option. This is more friction but is honest about what the library actually needs.

Whichever you pick, please update the sample.conf wording to match - right now the comment says credential_scopes is "Required for public-GCP service-accounts" but the code silently fills it in, so the docs and behavior disagree.

[skartikey]

@crflanigan A couple of comments.
CI: gofmt failure on the new field line is what's failing lint-linux/macos/windows. make fmt will fix it.

[telegraf-tiger]

Download PR build artifacts for linux_amd64.tar.gz, darwin_arm64.tar.gz, and windows_amd64.zip.
Downloads for additional architectures and packages are available below.

☺️ This pull request doesn't significantly change the Telegraf binary size (less than 1%)

📦 Click here to get additional PR build artifacts

Artifact URLs

. DEB	. RPM	. TAR . GZ	. ZIP
amd64.deb	aarch64.rpm	darwin_amd64.tar.gz	windows_amd64.zip
arm64.deb	armel.rpm	darwin_arm64.tar.gz	windows_arm64.zip
armel.deb	armv6hl.rpm	freebsd_amd64.tar.gz	windows_i386.zip
armhf.deb	i386.rpm	freebsd_armv7.tar.gz
i386.deb	ppc64le.rpm	freebsd_i386.tar.gz
mips.deb	riscv64.rpm	linux_amd64.tar.gz
mipsel.deb	s390x.rpm	linux_arm64.tar.gz
ppc64el.deb	x86_64.rpm	linux_armel.tar.gz
riscv64.deb		linux_armhf.tar.gz
s390x.deb		linux_i386.tar.gz
		linux_mips.tar.gz
		linux_mipsel.tar.gz
		linux_ppc64le.tar.gz
		linux_riscv64.tar.gz
		linux_s390x.tar.gz

[crflanigan]

All set @skartikey @srebhan

Thanks for the feedback!