close() does not work instantly on streaming requests

I am writing a multi-threaded application, where one thread is using `iter_lines` to get data line-by-line from a streaming API with low latency but no consistent frequency.  
I needed a way to gracefully stop that thread, so I tried calling `close()` on the request object from the main thread. I then found out close does not close the connection

## Expected Result

`iter_lines` should stop close to instantly once the underlaying response was closed.

## Actual Result

`iter_lines` keeps blocking until the next data arrives from the server.
`close()` is also blocking until then.

```
...84.5876732 started 0x7f314ad61e90
...84.5878367 Got line: 'start'
...86.5874267 closing 0x7f314ad61e90
...89.59543 Got line: 'e'
...89.5955482 exit
...89.5958514 done
```

## Reproduction Steps

```python
#! /usr/bin/env python3
import requests
import threading
import time

def print_t(*args):
    print(time.time(), *args)

print_t("starting server")

# example streaming api using flask and a generator
def run_server():
    from flask import Flask, Response

    app = Flask("TestServer")

    @app.route("/get_lines")
    def get_lines():
        def generator():
            yield "start\n"
            time.sleep(5)
            yield "end\n"
        return Response(generator(), mimetype="text/plain", )

    app.run("127.0.0.1", 5555)

threading.Thread(target=run_server, name="ServerThread", daemon=True).start()
time.sleep(1)

print_t("Server started")

class worker:
    def get_lines(self):
        self.r = requests.get("http://127.0.0.1:5555/get_lines", stream=True)
        print_t("started", hex(id(self.r)))
        for line in self.r.iter_lines(chunk_size=1, decode_unicode=True):
            print_t(f"Got line: '{line}'")
        print_t("exit")

    def stop(self):
        print_t("closing", hex(id(self.r)))
        self.r.close()
        print_t("done")

w = worker()
threading.Thread(target=w.get_lines, name="getter_thread").start()
time.sleep(2)
w.stop()
```

## System Information
```
python3 -m requests.help
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.7.5"
  },
  "platform": {
    "release": "5.3.0-40-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.21.0"
  },
  "system_ssl": {
    "version": "1010103f"
  },
  "urllib3": {
    "version": "1.24.1"
  },
  "using_pyopenssl": false
}

```


It's not documented to behave the way you thought it _might_. It's not a bug because it's documented that the socket has to be exhausted (all data has to have been read from the socket) before calling `close()` last time I checked

Ok didn't see that in the docs and misinterpreted the `unless you consume all the data or call Response.close.` then.

I'll guess the only way to do what i want would be reading the data manually then, since `iter_content` has the same problem.

And "Ability to close streaming connections early" would be feature request then.

I'm not a maintainer but it's not something supported by urllib3 iirc so the feature-request belongs there as we rely 99% on them to support something like this

@NovaNekmit, sigmavirus24 is right that this would need to be supported at a lower level than Requests. urllib3 doesn't currently have support for this and until they move off of Python's standard http implementation, I don't know how feasible this would be.

I'd recommend following up there to track the feature request. Thanks!