Cannot stream both request and response at the same time

It appears to not be possible to use a generator for the data and `stream=True` and expect to be able to iterate over `resp.iter_lines()` at the same time.

## Expected Result

I expected to be able to send request data from a generator, and read response data with `resp.iter_lines`, at the same time.

## Actual Result

The library seemingly waits until all `data` is sent before `resp.iter_lines` produces any ouptut.

## Reproduction Steps

With a `server.py` using `flask==1.1.2`:

```python
from flask import Flask, Response, request, stream_with_context

app = Flask('bug')

@app.route('/bug', methods=['POST'])
def bug():
    def resp():
        while True:
            line = request.stream.readline()
            print(line)
            if line:
                yield 'Bye\n'
            else:
                break

    return Response(stream_with_context(resp()))

app.run()
```

And a `client.py` using `requests==2.25.1`:

```python
import requests
import time

def req():
    for _ in range(10):
        yield b'Hi\n'
        time.sleep(0.5)

resp = requests.post("http://localhost:5000/bug", data=req(), stream=True)
for line in resp.iter_lines():
    print(line)
```

By running `server.py` in one console and then `client.py` in another, it can be seen that the server correctly prints the incoming request data every 0.5s, while the client prints all lines immediately after 5s.

I have also tried with a different library, `aiohttp`, and this seems to be capable of streaming both request and response at the same time.

Note that iterating over `resp.iter_lines()` in a different thread doesn't make it work either, although I would expect it to work with a single thread.

<details><summary>Threaded code</summary>

```python
import requests
import time
import threading

def req():
    for _ in range(10):
        yield b'Hi\n'
        time.sleep(0.5)

def handle_resp(resp):
    for line in resp.iter_lines():
        print(line)

threading.Thread(
    target=handle_resp,
    args=(requests.post("http://localhost:5000/bug", data=req(), stream=True),)
).start()
```

</details>

## System Information

<details><summary>$ python -m requests.help</summary>

```json
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.10"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.9.1"
  },
  "platform": {
    "release": "10",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.25.1"
  },
  "system_ssl": {
    "version": "1010107f"
  },
  "urllib3": {
    "version": "1.26.2"
  },
  "using_pyopenssl": false
}
```

</details>

I’ve noticed this too. I believe this is unfortunately a known issue with status WONTFIX (and can try to find a reference to a previous issue later if no one beats me to it), but please correct me if I’m wrong.

A separate but related issue that I think has also been reported before and is in the same category: If you use requests to make a request with a body (no matter how large), it waits for the server to read the entire request body before it tries to read the server’s response. But if e.g. the server requires authentication and the request was sent without credentials, production-quality servers will not read arbitrarily large request bodies before sending a 401 response (as a DoS protection), causing an uncaught ConnectionError (broken pipe) in requests (since it expects the server to read the request body in its entirety before it tries to read the response), and making the 401 challenge response negotiation impossible for requests auth extensions like requests_kerberos.

@jab you're correct. Anything built on http.client suffers the problem you described

Thanks for the feedback, I guessed this issue was already reported, and I tried to [search for "stream request response"](https://github.com/psf/requests/issues?q=is%3Aissue+stream+request+response) in the list of issues but with nearly 300 issues it was hard to identify the right one, if it was there at all with my query :P

As a workaround, I'll be using `aiohttp` 3.7.3 which seems to work fine, in case someone has this same issue in the future.