Add container-based config discovery support for haproxy

[martavicentenavarro]

What does this PR do?

Adds a container-based config discovery block for the haproxy integration, so Autodiscovery can generate a working instance config from a discovered haproxy container without manual setup.

• assets/configuration/spec.yaml: adds a from_ports discovery strategy targeting port 8404 (HAProxy's own documented Prometheus-exporter convention — see haproxy.com's Prometheus exporter tutorial), generating an instance with use_openmetrics: "true" and openmetrics_endpoint set. The manual from_ports form (rather than the openmetrics_from_ports template) is required because the check's __new__ dispatch needs the use_openmetrics flag alongside the endpoint, not just the endpoint.
• Adds an auto_conf.yaml files-entry (ad_identifiers: [haproxy]) so the config is picked up by name.
• Regenerates config_models/discovery.py, discovery_overrides.py, discovery_strategies.py, and data/auto_conf.yaml via ddev -x validate config/models -s haproxy.
• Wires tests/conftest.py's dd_environment fixture with get_e2e_discovery_metadata() so the E2E Agent container can read the target container's labels/ports.
• Adds test_e2e_discovery (validates real metric collection through a fully-discovered instance) and test_e2e_discovery_all_candidates (validates every generated candidate against the live container without crashing it) to tests/test_e2e.py.
• Bumps the datadog-checks-base floor to 37.41.0 for the discovery framework APIs used above.

Scope and limitations

This PR intentionally supports only HAProxy containers exposing the Prometheus exporter on port 8404 with the conventional /metrics path.

Legacy stats-page mode is not auto-discovered because it can require operator-provided credentials and a deployment-specific stats URL, which cannot be safely synthesized by Autodiscovery.

Deployments exposing the Prometheus exporter on a different path will still need manual configuration.

Motivation

Part of the Discovery team's broader Autodiscovery rollout across integrations-core checks (DSCVR-515).

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Add qa/required if this PR needs QA validation, or qa/skip-qa if it does not. Exactly one of the two is required.
• If you need to backport this PR to another branch, you can add the backport/<branch-name> label to the PR and it will automatically open a backport PR once this one is merged

[datadog-prod-us1-5]

 

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 94.45% (+6.16%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: b7aed48 | Docs | Datadog PR Page | Give us feedback!}

[dd-octo-sts]

Validation Report

All 21 validations passed.

Show details

Validation	Description	Status
agent-reqs	Verify check versions match the Agent requirements file	✅
ci	Validate CI configuration and code coverage settings	✅
codeowners	Validate every integration has a CODEOWNERS entry	✅
config	Validate default configuration files against spec.yaml	✅
dep	Verify dependency pins are consistent and Agent-compatible	✅
http	Validate integrations use the HTTP wrapper correctly	✅
imports	Validate check imports do not use deprecated modules	✅
integration-style	Validate check code style conventions	✅
jmx-metrics	Validate JMX metrics definition files and config	✅
labeler	Validate PR labeler config matches integration directories	✅
legacy-signature	Validate no integration uses the legacy Agent check signature	✅
license-headers	Validate Python files have proper license headers	✅
licenses	Validate third-party license attribution list	✅
metadata	Validate metadata.csv metric definitions	✅
models	Validate configuration data models match spec.yaml	✅
openmetrics	Validate OpenMetrics integrations disable the metric limit	✅
package	Validate Python package metadata and naming	✅
qa-label	Validate the pull request declares whether it needs QA for the next Agent release	✅
readmes	Validate README files have required sections	✅
saved-views	Validate saved view JSON file structure and fields	✅
version	Validate version consistency between package and changelog	✅

View full run