Validate built-in transport kwargs

[ahmedtaha100]

Summary

This change fixes unsupported per-request keyword arguments leaking through built-in transports into the underlying HTTP libraries.

Previously, kwargs passed through Pipeline.run(...) or AsyncPipeline.run(...) could be forwarded unchanged into transports such as aiohttp, requests, trio-backed requests, or httpx. That could produce backend-specific failures, including the reported async aiohttp path where query_filter reached aiohttp.ClientSession.request(...).

The fix validates kwargs inside each built-in transport's send() method, after known supported transport options are consumed and before the backend HTTP client is called. If unsupported kwargs remain, the transport raises a clear Python-style TypeError, for example:

AioHttpTransport.send() got an unexpected keyword argument 'query_filter'

Custom transports are intentionally unchanged. Pipeline-level kwargs are still passed through to custom transport implementations, so third-party transports can continue accepting their own options.

Transports covered

• azure-core: RequestsTransport, AioHttpTransport, AsyncioRequestsTransport, TrioRequestsTransport
• corehttp: RequestsTransport, AioHttpTransport, HttpXTransport, AsyncHttpXTransport

Notes

• Supported kwargs are consumed explicitly where each transport supports them.
• aiohttp ssl and server_hostname request options are supported explicitly so custom token-binding/SNI transports can pass valid aiohttp options through.
• Leftover unknown kwargs are rejected before reaching requests, aiohttp, or httpx.
• corehttp httpx transports reject per-request connection_verify and connection_cert because httpx applies TLS configuration at client construction.
• Both azure-core and corehttp CHANGELOGs document this under ### Breaking Changes.
• Regression tests cover direct transport calls, pipeline-level calls, the original async failure path, aiohttp SSL/SNI passthrough, and custom transport passthrough.

Fixes #46365

Validation

• PYTHONPATH=sdk/core/azure-core;sdk/core/corehttp;sdk/identity/azure-identity python -m pytest sdk/core/azure-core/tests/test_basic_transport.py sdk/core/azure-core/tests/async_tests/test_basic_transport_async.py sdk/core/azure-core/tests/test_pipeline.py -q
• PYTHONPATH=sdk/core/azure-core;sdk/core/corehttp;sdk/identity/azure-identity python -m pytest sdk/core/corehttp/tests/test_transport.py sdk/core/corehttp/tests/async_tests/test_transport_async.py sdk/core/corehttp/tests/test_pipeline.py -q
• PYTHONPATH=sdk/core/azure-core;sdk/core/corehttp;sdk/identity/azure-identity python -m pytest sdk/identity/azure-identity/tests/test_workload_identity_credential_async.py -q
• python eng/tox/run_black.py -t sdk/core/azure-core
• python eng/tox/run_black.py -t sdk/core/corehttp
• python eng/tox/run_pylint.py -t sdk/core/azure-core
• python eng/tox/run_pylint.py -t sdk/core/corehttp

SDK Contribution checklist

• This pull request introduces an intentional breaking change, documented in both CHANGELOGs.
• CHANGELOG is updated for both azure-core and corehttp.
• I have read the contribution guidelines.

General Guidelines and Best Practices

• Title of the pull request is clear and informative.

Testing Guidelines

• Pull request includes test coverage for the included changes.

[github-actions]

Thank you for your contribution @ahmedtaha100! We will review the pull request and get back to you soon.

[ahmedtaha100]

I looked through the current failing checks.

The red python - pullrequest status comes from the Windows build in build 6211631. The visible failure is in pipeline cleanup (Remove-Item on tags.json with an IOException), followed by downstream matrix/pool resolution failures. I don’t see a Python test failure there; the failure appears to happen before the test stages are prepared.

The red python - cosmos - ci status comes from build 6211629, specifically Test windows2022___EmulatorTestsPython310Standard. The failing test is tests/test_service_retry_policies.py::TestServiceRetryPolicies::test_service_response_retry_policy, where the retry counter was 1 instead of 3. This is in sdk/cosmos/azure-cosmos; the same job’s wheel run passed, and the other Cosmos variants passed.

I’m not planning to push a code change for these unless maintainers see something in the logs that points back to this PR.