Upgrade Windows Telegraf to 1.40.0

[zanejohnson-azure]

Summary

Upgrade the official upstream-built Windows AMD64 Telegraf package from 1.24.2 to 1.40.0. This consumes upstream's node-discovery token-file reload on retries after a failed poll, allowing discovery to recover after token rotation without relying on file modification time or restarting Telegraf.

• Pin the ZIP SHA256 and fail installation on download, checksum, extraction, or move errors; retain the existing runtime path and OSS signing flow.
• Preserve the overall 15-second metric-scrape timeout using timeout rather than the newer response-header-only response_timeout.
• Migrate Windows templates and namespace-generated plugins to fieldinclude/fieldexclude, while keeping public ConfigMap fieldpass/fielddrop keys and Linux rendering unchanged.
• Migrate the optional process-metrics configuration from removed pid_tag to tag_with = ["pid"], preserving process selection, CPU/RSS fields, and telemetry tags.
• Add package/configuration regression coverage and document provenance, compatibility, and remaining limitations.

Package provenance

• Upstream source: e9017dc3266369d6fa185e0e130af1d1d4021ce9, with vcs.modified=false in the downloaded executable.
• ZIP SHA256: 9d85e3fa89d99e4b0e53e4aa40f069e828204cf5548ede9b9b7c95c31fe869dd.
• Executable: Go 1.27.0, windows/amd64, GOAMD64=v1. LTSC2019 and LTSC2022 meet Go's documented Windows OS floor; this does not substitute for image validation.

Scope and remaining limitations

This is a stock-package upgrade / partial mitigation, not a Telegraf source patch, backport, or source-build workflow. The upstream non-200 response-body cleanup defect and unbounded cAdvisor discovery requests remain unfixed. The metric-scrape timeout does not bound discovery. No HTTP/2, kubelet, TLS, or authentication workarounds are introduced.

Independent of #1782: kubernetes/windows/main.ps1 and the WS2025 startup behavior are unchanged. Based on ci_prod commit 8e6bef5637c8d0e1e52299cfb2bd9ecb3645a8ca.

Completed validation

• Ruby configuration suite: 43 tests, 560 assertions, including the actual Windows 1.40.0 executable loading generated unfiltered, empty-filter, and namespace-filtered configs with default strict environment handling.
• Package regression: 52 assertions under Windows PowerShell 5.1, covering pinned acquisition paths, checksum mismatch, and failure ordering.
• Native-host process-metrics --console --test: migrated configuration loads and emits CPU/RSS metrics with PID tags; output plugins are not run.
• Bounded loopback-only stock-binary simulation over HTTP/1.1: the same process continued using token A during successful polls, then reread token B after a synthetic A-token 401. Token path/file identity/mtime were unchanged; fresh-token discovery succeeded approximately 1 second after the 401, followed by actual new-target metrics. Execution completed in 7.725 seconds under a 30-second ceiling. The retained error-response connection was still observed, consistent with the deferred cleanup defect.

The rotation fixture used a synthetic kubeconfig tokenFile, not a real projected mount, in-cluster credential configuration, installed Windows service, or deployed image.

Remaining validation

• Build the Windows images from this branch through the image pipeline.
• Exercise the resulting signed LTSC2019/LTSC2022 images and installed-service operation.
• Validate projected-token rotation and continued/new-target discovery in an authorized cluster.

No image build, deployment, live-cluster change, or SCM service installation/restart was performed as part of this change.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.