ConnectionError BadStatusLine on Python 3.8 on macOS

We are using a thread-based HTTP server, and on the client side the `requests.post()` method raises:
```
ConnectionError: ('Connection aborted.', BadStatusLine('POST / HTTP/1.1\r\n'))
```
The exception happens only every now and then, and is not really predictable. Sometimes, it happens after 100+ successful POSTs.

It only happens on Python 3.8 (presumably only on 3.8.5) and only on macOS on Travis (where the macOS is virtualized, I believe). I was not able to reproduce it on a local MacBook with Python 3.8.5 (and the exact same set of Python packages in the Python virtualenv).

I have isolated the code into a standalone demo that reproduces the issue (on Travis, see above), and that contains both the minimalized HTTP server code, and the pytest test case that sends the POSTs, all in a single standalone Python module named `test_demo_listener.py` that is designed to be invoked by pytest. The test is serialized, i.e. there is only one client sending POSTs against the server. There is a variable that sets the log level. If you want me to make modifications to the code, just let me know.

The server is a thread-based HTTP server derived from `socketserver.ThreadingMixIn` and `http.server.HTTPServer` and runs in a separate thread from the test thread, but in the same Python process.

The only test case in that module creates a HTTP server object, starts its thread, and sends N POSTs to it via localhost, all in the same Python process. The pytest parametrization repeats this test case 10 times for N=10, and then 10 times for N=100.

The full-fledged server from our project showed this error in many Travis runs by now. Issue https://github.com/pywbem/pywbem/issues/2383 lists a number of them in order to find out whether there is some rule to it: The issue happens always in the series with N=100, in one of the first two or three repetitions. Once the issue has happened, it never happens again in that Python process (pytest considers the parametrizations of the test case function to be different test cases, so it continues executing the remaining test cases if one is unsuccessful). I suspect these rules also apply to the minimalistic standalone server.

This PR https://github.com/pywbem/pywbem/pull/2402 contains the standalone Python module mentioned above, and its Travis run https://travis-ci.org/github/pywbem/pywbem/jobs/715557420#L5191 shows the exception (which in this case happened at POST 40 in the 3rd repetition of the 100-series).

## Expected Result

I expected no such exception to be raised.

## Actual Result

See above.

## Reproduction Steps

Caveats:
1. I only saw this in macOS in Travis, with Python 3.8.5
2. It only happens sometimes in each pytest run shown below

With these caveats, to reproduce, have `requests`, `pytest` and `six` installed and the standalone test module in the current directory and then run:
```
$ pytest test_demo_listener.py -s
```

## System Information

This is admittedly my local macOS, but I verified that Python version and package versions are the same as on Travis.

```
$ python -m requests.help
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.10"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.8.5"
  },
  "platform": {
    "release": "19.5.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.24.0"
  },
  "system_ssl": {
    "version": "1010107f"
  },
  "urllib3": {
    "version": "1.25.10"
  },
  "using_pyopenssl": false
}
```

Hi @andy-maier, I'm not sure if you've resolved this but I took a quick look at this issue. The server in question appears to be periodically confused. This may be due to a threading issue or some other defect. You can see that we've received a [Status Line](https://datatracker.ietf.org/doc/html/rfc7230#section-3.1.2) from the server which should be in the form `HTTP-version SP status-code SP reason-phrase CRLF` (i.e. `HTTP/1.1 200 OK\r\n`). The value we received though is actually a _Request Line_ (`POST / HTTP/1.1\r\n`).

This is showing us the server is responding with its own request which is just plain wrong. I don't think there's anything for Requests to do in this case as the responding server isn't following the HTTP protocol in this case.