feat(outputs.wavefront): Add more auth options and update SDK

[LukeWinikates]

• Updated associated README.md.
• Wrote appropriate unit tests.
• Pull request title or commits are in conventional commit format

This PR updates the Wavefront output plugin to use the latest version of the Wavefront Go SDK. The new version adds support for additional authentication flavors, and a configuration setting for opting out of sending internal SDK metrics.

[LukeWinikates]

Wavefront is transitioning from 1 supported authentication flavor to 3.

For now we'll continue to have the API token option we've always had, but moving forward we'll also have two "CSP" options - CSP is VMware's OAuth provider for VMware products.

These options all have different required fields, and putting them into the top-level TOML document for the output is proving hard to document, and makes for a messy conditional code path.

I would be interested in doing something like:

[[outputs.wavefront]]
url = "https://metrics.wavefront.com"

[[outputs.wavefront.authentication]]
kind = "wavefront-token"
token = "my-token"

[[outputs.wavefront.authentication]]
kind = "csp-api-token"

[[outputs.wavefront.authentication]]
kind = "csp-client-credentials"

or maybe the sub-table would be [[outputs.wavefront.csp-token]], etc without the kind field?

I couldn't find a precedent for that pattern in the Telegraf codebase. Is it worth pursuing? Do any Telegraf folks have any suggestions for how to manage this situation?

We're not happy with the documentation of the fields in the sample config right now - based on responses to the above, we'll improve that documentation before merge.

[srebhan]

Thanks for the nice update @LukeWinikates! Two minor comments from my side...

Regarding the option scheme/strategy: I think we can keep the top-level options (and the ifs) if we don't expect the number of options to grow much more... However, if you like like I would create auth-style specific structs and option-tables like [wavefront.auth_csp_api], [wavefront.auth_csp_app], etc.

[LukeWinikates]

@srebhan thanks for your feedback and for the suggestion about the sub-table solution. Since only the client credentials option has several fields to configure, I only extracted a sub-table for that one. I tested the build artifacts on my team's side. I think this PR is ready to be squashed and merged - let us know if you see any other changes we need to make.

[srebhan]

There is one problem with the config layout due to TOML's handling of "tables", see my comment in the code...

[LukeWinikates]

@srebhan I think this is good to go now! Not sure why the windows test fails.

[srebhan]

I will push the two whitespace fixes and then we are good.

[powersj]

Thanks for the updates. Some comments around the README/sample config. Remember to update in both places.

[telegraf-tiger]

Download PR build artifacts for linux_amd64.tar.gz, darwin_amd64.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

[powersj]

Thank you for the continued updates and shepherding of the plugin.