Which issue(s) does the PR fix:

Fixes #18387

[FEATURE] Scrape: add `dns_refresh_interval` to `scrape_config` to periodically close idle HTTP connections and force DNS re-resolution for FQDN targets.

What does this PR do?

Adds a dns_refresh_interval field to ScrapeConfig. When set, a background goroutine periodically calls client.CloseIdleConnections() on the scrape pool's HTTP client, forcing a fresh TCP dial — and therefore DNS re-resolution — on the next scrape cycle.

This fixes the case where a target is addressed by FQDN (e.g. a CNAME that points to a changing A record) and Prometheus continues connecting to a stale IP because http.Transport reuses idle TCP connections indefinitely; DialContext (and thus the OS resolver) is only invoked when a new connection is opened.

Why this approach?

Root cause analysis (from the issue thread): the bug is in the scrape layer's connection reuse, not in Consul SD or any other SD mechanism. Any SD that provides an FQDN in __address__ is affected.

The fix is opt-in: the zero value (default) disables the behaviour and preserves existing connection-reuse semantics. The approach mirrors discovery/dns's refresh_interval pattern already present in the codebase.

Changes

• config/config.go: adds DNSRefreshInterval model.Duration to ScrapeConfig
• scrape/scrape.go: adds dnsRefreshInterval to scrapePool; wires it from config in newScrapePool and reload; adds runDNSRefresh() goroutine
• scrape/scrape_test.go: adds TestScrapePoolDNSRefresh verifying that CloseIdleConnections is called at the configured interval

Example config

scrape_configs:
  - job_name: my-fqdn-targets
    dns_refresh_interval: 30s   # re-resolve DNS every 30 seconds
    consul_sd_configs:
      - server: consul.example.com

Design question for maintainers: periodic flush vs DNS-aware detection

I want to be upfront about a gap between this implementation and the language used in the issue thread.

@bwplotka's comment on the issue says "detecting DNS changes", which implies the ideal solution would only force reconnection when the resolved IP actually changes — DNS-aware detection. This implementation takes a simpler but broader approach: it blindly calls CloseIdleConnections() on a fixed timer, which drops all idle connections for the scrape pool (not just those whose DNS record changed), regardless of whether the IP is still the same.

Concretely, the two approaches differ in blast radius:

The DNS-aware approach would require wrapping the DialContext used by the scrape pool's http.Transport to cache the last-resolved IP per hostname and force a new dial when it changes. This is more surgical but more complex (and requires storing per-host resolver state).

Question for reviewers: Is the periodic CloseIdleConnections() approach acceptable here, or would you prefer the DNS-aware DialContext wrapper? Happy to implement the more targeted approach if that's the direction — wanted to surface this trade-off before investing further.

Open questions

1. Should there be a global default in GlobalConfig (like scrape_interval has), or is zero/disabled the right default?
2. Is dns_refresh_interval the right name, or would something like connection_refresh_interval be more accurate (since CloseIdleConnections affects all idle connections, not just DNS-backed ones)?
3. Any preference on whether the goroutine lives on scrapePool (as implemented) vs a ticker inside scrapeLoop.run() — the pool approach calls CloseIdleConnections once for all loops in a job, which seems preferable.

/cc @bwplotka @mrvarmazyar @roidelapluie