trust_env has diverging defaults between Client and create_ssl_context

[florimondmanca]

Right now there's a slight discrepancy for the default value of trust_env for httpx.Client() / httpx.AsyncClient() and httpx.create_ssl_context().

• Clients use trust_env=True as a default.
• create_ssl_context uses trust_env=None as a default.

In practice, it means that Client() has SSLKEYLOGFILE support enabled by default, while Client(verify=create_ssl_context()) has it disabled — which is non-intuitive.

Note that create_ssl_context() was introduced via #996, but the defaults pre-date that PR since it was already defined on the internal SSLConfig class. Instead, the introduction of trust_env=None there actually dates back from #301 (SSLKEYLOGFILE support). There was actually a conversation there about this, but it remained unresolved: #301 (comment)

What would we say about setting the default to True though […]?

All references to trust_env use True as the default. This inconsistency also makes #1302 a bit less intuitive, because:

import httpx

transport = httpx.HTTPTransport()

# This is NOT equivalent:
transport = httpx.HTTPTransport(ssl_context=httpx.create_ssl_context())
# Users might do this^, and expect eg SSLKEYLOGFILE to be enabled, but it won't...

# They'd need to pass an explicit `trust_env=True`...
transport = httpx.HTTPTransport(ssl_context=httpx.create_ssl_context(trust_env=True))

To be clear, this only affects SSLKEYLOGFILE support. NETRC support and env-based proxies are not affected since those are managed at the client-level, which already sets trust_env=True.