os.environ lowercase takes precedence over uppercase

I wonder if there is a specific reason for the lowercase http_proxy to take precedence over its uppercase version (same behavior for the other os.environ). The convention is to use uppercase for environment variables and setting both could potentially lead users to unexpected behavior.

https://github.com/requests/requests/blob/master/requests/utils.py#L699

Can someone give me the original reason why things have been done like this?

Thanks!

## System Information

    $ python -m requests.help
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "2.7.13"
  },
  "platform": {
    "release": "4.9.85-38.58.amzn1.x86_64",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "100020bf"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}

Hi @ZuZuD, to clarify, your concern is about `no_proxy` being given precedence over `NO_PROXY`? I believe the lambda function was designed to give preference to whatever casing it was handed first, and then attempt to find an uppercased version if that did not work.

The `no_proxy` check was added later (#945) and I believe chose lowercase for scoping issues. A lowercased environment variable is conventionally used to represent a "local" scope environment variable, where as an uppercased name is considered global and likely spans sessions. We're giving preference to the local scope first before looking for something in global scope, because it's considered to be more specific.

Thank you for your complete answer @nateprewitt ! By curiosity I took a look at other http libraries/software to assess their behavior regarding those env variables.

1) curl: lowercase takes precedence over uppercase https://github.com/curl/curl/blob/master/lib/url.c#L2659

```
$ ~/github/curl export HTTPS_PROXY=0.0.0.0
$ ~/github/curl curl -i https://github.com
$ curl: (7) Failed to connect to 0.0.0.0 port 1080: Connection refused

$ ~/github/curl export https_proxy=localhost
$ ~/github/curl curl -i https://github.com
$ curl: (7) Failed to connect to localhost port 1080: Connection refused
```
More surprisingly, it also ignores HTTP_PROXY https://github.com/curl/curl/blob/master/lib/url.c#L2648

2) wget: only parse lowercase variables and doesn't take into consideration uppercase variants
https://github.com/mirror/wget/blob/master/src/retr.c#L1450

Therefore it is a consistent behavior so far as they all favor lowercase usage, which could be another good reason.




That does make sense @ZuZuD. I know some of our behaviour tries to model curl in the places where it makes sense. Would you be willing to add a comment to the code to clarify that for future maintainers and contributors? That would be incredibly helpful to have as these issues may not persist for the full length of our project. :smile: 

And @ZuZuD, *thank you so much* for researching that. I greatly appreciate your effort into finding out those other behaviours and helping this project improve.

Closing this out since #4583 was merged. Thanks again @ZuZuD!