chore(deps): Bump prometheus from v1.8.2 to v2.42.0

[LukeWinikates]

This PR updates the prometheus package to v0.42, currently the second-newest version.

Bumping prometheus allows us to also bump a few kubernetes-related packages, and this PR also includes code changes required for compatibility with those versions.

This PR is adapted from: #13159
That PR tries to update to v0.43, but v0.43 causes build errors that can't currently be resolved.

[powersj]

I saw this in the other PR and it made me pause. We are ignoring these errors right now, is this going to cause instances where things are working today to stop working?

[LukeWinikates]

Yeah, that's fair. I wouldn't have touched this except for the linter requesting some kind of error handling, now that the underlying API returns an error.

I'll update the PR to log the error and continue, so that the behavior should be the same as what currently happens, with the addition of a warning message in the logs.

[LukeWinikates]

Ok:

• switched to p.Log.Warnf, thinking that this is a non-fatal warning.
• no longer calling <-ctx.Done() early if AddEventHandler returns an error. Keeping the control flow the same as it was, with the addition of capturing the error and returning it from watchPod

[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 increases the Telegraf binary size by 1.32 % for linux amd64 (new size: 175.1 MB, nightly size 172.8 MB)

📦 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

[srebhan]

Looks good to me. Thanks @LukeWinikates for the PR and for fixing the remaining issues!

[msenskp]

@LukeWinikates A naive question as I do not know go lang: I see the Prometheus releases are tagged both with v0.42.0 and v2.42.0 at the same time. I am not sure why it is versioned like this but is it possible to upgrade the versions into v2.4+ as the commit message itself specify here https://github.com/LukeWinikates/telegraf/blob/7d3b725f62c27bbbf6566d081ba08f0b5d73d56f/go.mod#L147

I noticed that this is confusing some CVE image scans for some tools such as this

Otherwise it sounds like we are moving backward from 1.8.2... to 0.42.0

[LukeWinikates]

@msenskp there's more context on the prometheus versions in #13159 and at https://github.com/prometheus/prometheus#prometheus-code-base

As I understand it, prometheus/prometheus isn't really meant to be used as a library (it's an application codebase), and so the code does not follow SemVer rules about API stability in the way that golang tooling expects. To get around the problem, the Prometheus project 'reset' the version numbers for the go package to all begin with 0, even though the corresponding application is 2.x.x. This solved the SemVer problem because 0. versions in SemVer are considered pre-release versions and are allowed to have breaking API changes in minor versions. But it does mean that you have to "downgrade" to "upgrade". Hopefully there is a way for you to mute that warning in the CVE scanner.

The longer term solution is probably this: #13165 .

[msenskp]

@LukeWinikates thank you for the insight. Also glad to hear that there is a long term solution plan with a smaller footprint on the dependencies.