fix: honour verify=False/ssl=False in HttpOptions client_args

[64johnlee]

Summary

Fixes #2557

When a user passes verify=False (httpx) or ssl=False (aiohttp/websocket) in HttpOptions.client_args to disable SSL certificate verification — a common need in air-gapped, corporate proxy, or local-dev environments — the SDK silently ignored it and replaced it with a default strict ssl.SSLContext.

Root cause

Three static helper methods (_ensure_httpx_ssl_ctx, _ensure_aiohttp_ssl_ctx, _ensure_websocket_ssl_ctx) used truthiness guards:

ctx = args.get('verify')   # user passed False → ctx = False
if not ctx:                # not False == True → enters branch
    ctx = ssl.create_default_context(...)  # overwrites False!

And inside _maybe_set:

if not args or not args.get(verify):   # not False == True → overwrites again
    args[verify] = ctx

Fix

Replace if not ctx: → if ctx is None: and not args.get(verify) → args.get(verify) is None in all three helpers (6 changes total). This correctly distinguishes "user explicitly set False" from "user provided nothing".

Input	Before	After
verify=False	replaced with ssl.SSLContext ❌	preserved as False ✅
verify=ssl.SSLContext(...)	preserved ✅	preserved ✅
verify absent	default ssl.SSLContext injected ✅	default ssl.SSLContext injected ✅

Tests

Added 5 unit tests to test_http_options.py covering all three helpers with False input and verifying the default-injection path still works. 15/15 pass; no new failures introduced (pre-existing 33 failures unchanged).

🤖 Generated with Claude Code

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.