Exhaustively reading content from Response, doesn't call close on the non-stream request.

<!-- Summary. -->

Iterating the full, non-stream content of a `Response`  flags the content as consumed:
https://github.com/psf/requests/blob/881281250f74549f560408e5546d95a8cd73ce28/src/requests/models.py#L832

Which in turn prevents the raw object being closed.
https://github.com/psf/requests/blob/881281250f74549f560408e5546d95a8cd73ce28/src/requests/models.py#L1021-L1028

This can result in a bunch of open resources waiting for GC to happen. I ran into this using the zeep library to read a couple of wsdl documents files, which can do a lot of requests for xsd documents using `file://` scheme; it raised a ResourceError too many open files.

mvantellingen/python-zeep#1393

## Expected Result

Since it is explicitly stated in the docs that when you want to manipulate `Response.raw` you need to set `stream`, I expect the reading in the non-stream case of the generator https://github.com/psf/requests/blob/881281250f74549f560408e5546d95a8cd73ce28/src/requests/models.py#L826-L830
to be done in a `contextmanagers.closing` block, so it will always be properly closed, even when exceptions occur. To protect the naive Human™ like myself.



## System Information

```json
{
  "chardet": {
    "version": "5.1.0"
  },
  "charset_normalizer": {
    "version": "2.0.2"
  },
  "cryptography": {
    "version": "41.0.3"
  },
  "idna": {
    "version": "2.10"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.10.12"
  },
  "platform": {
    "release": "6.1.0-0.deb11.11-amd64",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "30100020",
    "version": "23.2.0"
  },
  "requests": {
    "version": "2.31.0"
  },
  "system_ssl": {
    "version": "101010ef"
  },
  "urllib3": {
    "version": "1.26.15"
  },
  "using_charset_normalizer": false,
  "using_pyopenssl": true
}
```


Requests is written first and foremost to leverage urllib3. It assumes that adapters will behave as urllib3 does (i.e., consuming the socket closes it). If the `file://` adapter that is used by zeep and either written by them or provided by some other library is not doing the correct thing there, that is not a requests bug.

Looking quickly at zeep's dependencies, they're using `requests-file` (which also looks largely unmaintained and more-or-less abandoned).

Specifically, https://github.com/dashea/requests-file/blob/675c7a6849bd5b2c271b503a3f51ea65599b34ec/requests_file.py#L87 seems like the fastest route but not necessarily the wisest. That said, looking at that code, they also set `release_conn` as an alias to `close` on that object here https://github.com/dashea/requests-file/blob/675c7a6849bd5b2c271b503a3f51ea65599b34ec/requests_file.py#L88 and https://github.com/dashea/requests-file/blob/675c7a6849bd5b2c271b503a3f51ea65599b34ec/requests_file.py#L106 which playing with that in a local REPL seems to work despite my expectation it wouldn't.

So looking back to _all_ of our `close` method (which hasn't been updated in 7 years), we have a fallback to that: https://github.com/psf/requests/blob/881281250f74549f560408e5546d95a8cd73ce28/src/requests/models.py#L1021-L1032 which would work if close were called.

In other words, if you're running into a GC issue with too many file handles open, something else either in zeep or your code is hanging on to unclosed file handles.