Catch agnostic HTTP error types across cloud_foundry_api and swap the test

[mwdd146980]

What does this PR do?

Widen the HTTP exception handling in cloud_foundry_api to catch the backend-agnostic HTTPError and HTTPStatusError types alongside the existing requests ones, and swap the tests to inject and assert the agnostic types.

Motivation

Part of the httpx migration. The agnostic http_exceptions hierarchy shares no base class with requests.exceptions, so the check must catch both families to keep working once the HTTP backend swaps to httpx. The connect handlers pair RequestException with the agnostic base HTTPError; the status handlers pair requests' HTTPError (aliased to RequestsHTTPError) with the agnostic HTTPStatusError. No observable behavior change under the shipped requests backend.

Verification

Full cloud_foundry_api unit suite passes. Confirmed red-then-green on the scroll_api_pages handlers: with the tests swapped to agnostic types and production left requests-only, the two scroll error tests fail with the agnostic HTTPError escaping the requests-only except; after widening, they pass. The four re-raise sites (discover_api, get_oauth_token) stay green either way and were verified by reading the handlers. ddev test -fs is clean.

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-4]

   

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 3 Pipeline jobs failed

PR | test / test-minimum-base-package (linux, ubuntu-22.04, cloud_foundry_api, Cloud Foundry API (py3.13), py... / minimum-base-package-Cloud Foundry API (py3.13)-py3.13     

Validate repository | Run Validations / Validate     

PR | test / check     

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 96.12% (+7.99%)

Useful? React with 👍 / 👎

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

[mwdd146980]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1fe6f4dc9a

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[dkirov-dd]

Approved too fast, could you switch the changelog type to fixed or something other than changed?

[dd-octo-sts]

Validation Report

Validation	Description	Status
dep	Verify dependency pins are consistent and Agent-compatible	❌

Run ddev validate all changed --fix to attempt to auto-fix supported validations.

Passed validations (20)

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	✅
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

[mwdd146980]

@dkirov-dd I'm using .changed because when the feature branch #22676 eventually does merge into master, I was thinking that a major version change will be warranted at that point. Should I still use fixed?