HTTP PUT does not follow redirections before sending the data

<!-- Summary. -->

Alternative title: *A bugfix in urlib3 raises a new bug in requests.* (I tried to figure out what changed in `urllib3` but was not able to do so).

I believe the issue has to do with these lines (https://github.com/psf/requests/blob/ac3be98b19f4d09c6a970b271a3ae30f3d0858f7/requests/adapters.py#L509-L539). It seems like the library is uploading the body with a `PUT` while it should first follow the redirection before uploading the body.

We've traced this down, confusingly, to different behavior for `requests` depending on the `urllib3` version.  Essentially, on an older `urllib3`, python `requests` will send the entire file twice(!) which can be time-consuming for larger files. This is **incorrect** behavior. Upon a `PUT` to a node that responds with a 307/redirect, `requests` sends the whole body then handles redirects, and then `PUT` again.

## Expected Result

I expected for a `PUT` request receiving a 307 to redirect and re-`PUT` (It does) but doesn't send data immediately until after redirects are resolved. This should probably behave more like what `curl` is doing (see output below).

## Actual Result

Data is sent immediately instead of checking for redirects, causing the file to be sent at least twice.

## Reproduction Steps

```python
import requests
import subprocess
import logging

# These two lines enable debugging at httplib level (requests->urllib3->http.client)
# You will see the REQUEST, including HEADERS and DATA, and RESPONSE with HEADERS but without DATA.
# The only thing missing will be the response.body which is not logged.
try:
    import http.client as http_client
except ImportError:
    # Python 2
    import httplib as http_client
http_client.HTTPConnection.debuglevel = 1

# You must initialize logging, otherwise you'll not see debug output.
logging.basicConfig()
logging.getLogger().setLevel(logging.DEBUG)
requests_log = logging.getLogger("requests.packages.urllib3")
requests_log.setLevel(logging.DEBUG)
requests_log.propagate = True

print("working with big file")
fpath = "big_file.txt"
fp = open(fpath, 'rb')

sever = "https:// .... " # our internal server

try:
    ret = requests.put(f"{server}", headers={"Content-Type":"application/octet-stream"}, data=fp, allow_redirects = True, stream = True)
    print(ret.status_code)
except Exception as exception:
    print(exception)
```

Meanwhile, `curl` seems to do the RightThing™ here:

```bash
$ time curl -L -v  https://server/large_file.txt --upload-file ./big_file.txt
* About to connect() to server port 443 (#0)
*   Trying ADDRESS...
* Connected to server(ADDRESS) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS: client certificate not found (nickname not specified)
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
*     subject: CN=CN_INFO
*     start date: Jun 27 21:45:02 2022 GMT
*     expire date: Aug 01 21:45:02 2023 GMT
*     common name: SERVER
*     issuer: CN=CN_AUTHORITY
> PUT /large_file.txt HTTP/1.1
> User-Agent: curl/7.29.0
> Host: server:443
> Accept: */*
> Content-Length: 1048576
> Expect: 100-continue
> 
< HTTP/1.1 307 TEMPORARY_REDIRECT
< Connection: Keep-Alive
< Server: XrootD/5.5.5
< Content-Length: 0
< Date: Tue, 20 Dec 2022 14:34:33 GMT
< ETag: "751376756371357696:00000000"
< Location: http://server_redirect/large_file.txt
< 
* Closing connection 0
* Issue another request to this URL: 'http://server_redirect/large_file.txt'
* About to connect() to server_redirect port 443 (#1)
*   Trying ADDRESS...
* Connected to server_redirect (ADDRESS) port 443 (#1)
> PUT /server_redirect/large_file.txt HTTP/1.1
> User-Agent: curl/7.29.0
> Host: server_redirect:443
> Accept: */*
> Content-Length: 1048576
> Expect: 100-continue
> 
< HTTP/1.1 100 Continue
< Connection: Close
< Server: OURSERVER
< Date: Tue, 20 Dec 2022 14:34:33 GMT
* We are completely uploaded and fine
< HTTP/1.1 201 CREATED
< Connection: Keep-Alive
< Server: OURSERVER
< Content-Length: 0
```

## System Information

    $ python -m requests.help

This (older) version silently works:

```json
{
  "chardet": {
    "version": "4.0.0"
  },
  "charset_normalizer": {
    "version": "2.0.12"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.10"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.7.9"
  },
  "platform": {
    "release": "22.1.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.27.1"
  },
  "system_ssl": {
    "version": "1010113f"
  },
  "urllib3": {
    "version": "1.26.3"
  },
  "using_charset_normalizer": false,
  "using_pyopenssl": false
}
```

This version breaks (correctly):

```json
{
  "chardet": {
    "version": null
  },
  "charset_normalizer": {
    "version": "2.1.1"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "3.4"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.10.6"
  },
  "platform": {
    "release": "22.1.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.28.1"
  },
  "system_ssl": {
    "version": "1010113f"
  },
  "urllib3": {
    "version": "1.26.13"
  },
  "using_charset_normalizer": true,
  "using_pyopenssl": false
}
```

In the future, please search **closed and** open issues before creating new ones that are duplicates.

There are *many* duplicates regardless of the confounder of urllib3 versions producing different behavior. What you're asking for has been discussed repeatedly for at least a decade and is not possible with python's current behavior and tools available. I won't go into detail because of how often this has been covered. 

> In the future, please search **closed and** open issues before creating new ones that are duplicates.
> 
> There are _many_ duplicates regardless of the confounder of urllib3 versions producing different behavior. What you're asking for has been discussed repeatedly for at least a decade and is not possible with python's current behavior and tools available. I won't go into detail because of how often this has been covered.

This is not what this report is about. An older version of `urllib3` had a bug that was fixed in a newer version. The bugfix raised a bug that has existed in `requests`. This is definitely not a duplicate.

@sigmavirus24 `requests` right now is currently crashing on a valid use case defined in the RFC for 307. This is still a valid bug report in my opinion and should not be closed.

@sigmavirus24 why does a PUT immediately upload some data before waiting for any reply from the server like curl is doing ?
If you get redirected, you will upload data twice: first to the headnode and then to the redirection destination...

Thanks in advance :)

Check closed and open issues. Neither library controls the socket and cannot read early. We can't read or see 100-continue. We can't get the 307 early. We don't write the data ourselves. And we're not in violation of the specification. Even if we were, we can't fix it ourselves. I'm not going to go into the details, again, because they are explained in excruciating detail elsewhere and it's not worth my time as you all have displayed a lack of respect for my time already by demanding an answer to something that is already answered.