chunk_size=None does not work as expected when streaming a response

Summary.

I have the following code to stream an SSE response.

```
resp = session.get(self.url, stream=True)
resp_iterator = resp.iter_content(decode_unicode=True, chunk_size=None)
while _some_condition():
    nextchar = next(resp_iterator)
    _add_to_buffer(nextchar)
```

## Expected Result

According to the [documentation](http://docs.python-requests.org/en/master/api/#requests.Response.iter_content), when chunk_size is None, it should stream the content as it is received. 

## Actual Result

No content is received by the consumer. It simply hangs. If I simply remove the chunk_size argument, I can see the consumer receiving 1 byte at a time.

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  }, 
  "cryptography": {
    "version": ""
  }, 
  "idna": {
    "version": "2.7"
  }, 
  "implementation": {
    "name": "CPython", 
    "version": "2.7.13"
  }, 
  "platform": {
    "release": "4.17.0-3rodete2-amd64", 
    "system": "Linux"
  }, 
  "pyOpenSSL": {
    "openssl_version": "", 
    "version": null
  }, 
  "requests": {
    "version": "2.20.1"
  }, 
  "system_ssl": {
    "version": "1010008f"
  }, 
  "urllib3": {
    "version": "1.24.1"
  }, 
  "using_pyopenssl": false
}
```

I suspect that this is an issue with urllib3's stream method that wasn't caught when it was changed.

https://github.com/requests/requests/blob/57d7284c1a245cf9fbcecb594f50471d86e879f7/requests/models.py#L750

The two modes within `HTTPResponse.stream()` (being `HTTPResponse.read()` and `HTTPResponse.read_chunked()`) both *appear* to support setting `amt=None` and it's the default parameter for all three. Do you know where that regression may have been introduced @sigmavirus24?

It'd be great to know what the headers are for the HTTP response you're getting here because a lot of the behavior within `HTTPResponse.stream()` is determined by a few headers.

As a quick FYI, I did some minimal debugging and this appears to only be reproducible with Requests and not with generic usage of urllib3. It's likely our adapters code may be doing something to the urllib3 Reponse object that isn't being tested for in Requests or urllib3.

**Requests Repro**
```python
import requests
r = requests.get('https://httpbin.org/get', stream=True)
for i in r.iter_content(chunk_size=0):
    print(i) # We hang on the first iter here at the line Sigmavirus24 noted
```

@sethmlarson, None and 0 appear to operate the same way, both causing hangs. I don't think we changed anything around this recently, but it may be something specific to how Requests is using urllib3. I'll have some time this weekend to do some poking to figure out what's going on.

Thanks for the repro! I'll step through it and see what I find. Also did you see my comment in the previous PR related to this issue?

EDIT: I wasn't able to reproduce a hang with Python 2.7.15 with the latest urllib3 using `chunk_size=None` but `chunk_size=0` definitely hangs indefinitely per my comment in the other PR.

Hi @hiranya911, after a closer look, it doesn't appear this is reproducible. A more concrete repro will terminate with a `StopIteration` exception. My best guess here is the server is failing to respond completely and when you go to consume the content, it's hanging indefinitely until the connection is terminated.

I don't believe there's a lot more we can do here presently without a repro that's available with public resources. If the case turns out that the connection is hanging, Requests doesn't have an ability to control that and the issue lies with the server. I'm going to close this for now, but feel free to reopen if you do find a reproducible example of a bug in the Requests code. Thanks!


**Basic Repro**
```python
import requests
  
count = 0

resp = requests.Session().get('https://www.google.com', stream=True)
resp_iterator = resp.iter_content(decode_unicode=True, chunk_size=None)
while count < 1000:
    nextchar = next(resp_iterator)
    count+=1

print(count)
```

@nateprewitt hi, is there really no way to detect such situations on the requests side? We're facing a similar problem right now, and it looks like we have to wait a lot until the connection is deemed dead before we can retry.