Read the CLI option environment variables the way they are documented

[feiiiiii5]

Two documented CLI options are unusable, and one of them is inverted:

$ CHECK_DELIVERABILITY=false python -m email_validator me@xkxufoekjvjfjeodlfmdfjcu.com
The domain name xkxufoekjvjfjeodlfmdfjcu.com does not exist.     # the check ran anyway

$ DEFAULT_TIMEOUT=5 python -m email_validator me@example.com
TypeError: validate_email() got an unexpected keyword argument 'default_timeout'

Both are in the same block of email_validator/__main__.py:

• the boolean options go through bool(), and since every non-empty string is truthy, CHECK_DELIVERABILITY=false / TEST_ENVIRONMENT=0 / =no all mean true — the check the user asked to turn off is the one that runs, DNS lookups included;
• DEFAULT_TIMEOUT is collected into the same options dict and forwarded as a keyword argument, but validate_email has no such parameter. The real knobs are its timeout argument and the module-level DEFAULT_TIMEOUT that caching_resolver() reads, so no value at all works.

The module's own docstring says "keyword arguments to validate_email can be set in environment variables of the same name but uppercase", the README documents these as check_deliverability=False, and the 2.0.0 changelog entry introduced the option reading — so both spellings are meant to work. The fix reads the falsy set explicitly (empty string, plus 0/false/no/off, case- and space-insensitive), which is a superset of what bool() used to reject, so nothing that works today changes, and it sets the module global for DEFAULT_TIMEOUT.

I used int() rather than float() because DEFAULT_TIMEOUT is declared as an int in __init__.py and every public timeout parameter in the library is Optional[int] — mypy rejects the float. The visible consequence is that DEFAULT_TIMEOUT=0.5 now raises ValueError instead of the old TypeError; if you would rather have fractional seconds, the consistent change is annotating DEFAULT_TIMEOUT: float and the timeout parameters, which is a bigger call than this PR should make on its own.

Test: pytest tests/test_main.py -k from_env fails on c0cc1bc — 13 of the 14 cases, with the DNS-failure text where the JSON is expected and the TypeError for the timeout — and passes on this branch. The whole suite is 331 passed / 1 deselected (that one needs real DNS). flake8 and mypy are clean.

I did not add a CHANGELOG entry under "In Development" — happy to if you want one.

[feiiiiii5]

Hi @JoshData — #175 has been open since late September with CI green, so this is the one nudge I planned.

Recap: two documented CLI options are unusable, and one is inverted. CHECK_DELIVERABILITY=false still runs the DNS check, because the option is read as a string and any non-empty string is truthy; and DEFAULT_TIMEOUT=5 dies with TypeError: validate_email() got an unexpected keyword argument 'default_timeout', because the CLI passes default_timeout where the function takes timeout.

The question I would most like settled, because it is the one where the README and the code disagree and I do not want to pick for you: the README documents DEFAULT_TIMEOUT as "a global default", but validate_email(..., timeout=...) is per-call and allow_smtputf8/allow_empty_local style defaults cannot be expressed globally. I implemented it as "the CLI's default when the caller does not pass one", which is what the wording says but not what a global would mean. Would you rather it rename the option to make the per-call scope clear, or should the global actually override a caller-supplied timeout?