Requests sends NUL characters in headers.

https://www.rfc-editor.org/rfc/rfc9110#section-5


## Expected Result

Some ValueError when I pass a NUL in header.

## Actual Result
```
< 00000000 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a # GET / HTTP/1.1..
< 00000010 48 6f 73 74 3a 20 31 32 37 2e 30 2e 30 2e 31 3a # Host: 127.0.0.1:
< 00000020 39 39 39 39 0d 0a 55 73 65 72 2d 41 67 65 6e 74 # 9999..User-Agent
< 00000030 3a 20 70 79 74 68 6f 6e 2d 72 65 71 75 65 73 74 # : python-request
< 00000040 73 2f 32 2e 32 38 2e 32 0d 0a 41 63 63 65 70 74 # s/2.28.2..Accept
< 00000050 2d 45 6e 63 6f 64 69 6e 67 3a 20 67 7a 69 70 2c # -Encoding: gzip,
< 00000060 20 64 65 66 6c 61 74 65 0d 0a 41 63 63 65 70 74 #  deflate..Accept
< 00000070 3a 20 2a 2f 2a 0d 0a 43 6f 6e 6e 65 63 74 69 6f # : */*..Connectio
< 00000080 6e 3a 20 6b 65 65 70 2d 61 6c 69 76 65 0d 0a 66 # n: keep-alive..f
< 00000090 6f 6f 20 3a 20 74 65 73 74 00 74 65 73 74 0d 0a # oo : test.test..
< 000000a0 0d 0a                                           # ..
```

Note the `00` between the `test`s.
## Reproduction Steps
In a shell, start a netcat to listen
```sh
$ nc -l -p 9999 -o /dev/stderr >/dev/null
```

```python
import requests
requests.get('http://127.0.0.1:9999', headers = {'foo ': 'test\x00test'})
```

## System Information

    $ python -m requests.help

```json
{
  "chardet": {
    "version": null
  },
  "charset_normalizer": {
    "version": "3.0.1"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "3.4"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.10.8"
  },
  "platform": {
    "release": "6.0.0-0.deb11.6-amd64",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.28.2"
  },
  "system_ssl": {
    "version": "101010ef"
  },
  "urllib3": {
    "version": "1.26.14"
  },
  "using_charset_normalizer": true,
  "using_pyopenssl": false
}
```

So there's a difference between generating header names or values with nul characters and users sending them.

In the past when we've tried to make rules like this more restrictive we've encountered significant push back as people use requests for penetration testing and other security tasks where being able to send invalid information is valuable.

I think we could fix this, but it would only serve to further reduce time to work on the project since about 2 of us ever manage to respond to issues and that takes up most of our time. This would generate more issues complaining that we closed this issue with user generated data 

I was using requests to send requests to OpenAPI services. Putting user input into the request headers, when I noticed this.
I hope the vast majority of users is trying to behave well and uses requests to package good behaviour in an easy to grok package. The burden for misbehaviour should be on the ones wanting such malice, the default should follow spec.

Feel free to close this issue as noise if you disagree. I'm sorry for the inconvenience, I was just trying to follow [the robustness principle](https://www.rfc-editor.org/rfc/rfc1122.html#page-12) and be a good netizen. I would have been willing to write code to solve this, but I trust you know your user base better than I do.

In all candor, what you're describing is how security breaks down in practice. "I shouldn't have to worry about X because the underlying libraries must handle that for me at all costs." Unfortunately, requests is _old_ and has too many users to introduce behaviour like this without careful consideration and planning. We could add a warning if we detect this that it'll be deprecated and actually introduce an exception for this in a few minor releases from now, but that will not fix your existing issue on a timescale that I expect you'll find reasonable.

> The burden for misbehaviour should be on the ones wanting such malice

Penetration testing isn't a malicious act. Many people do it proactively to understand the behaviour of their systems under unexpected inputs. There are many layers to verifying that you do the correct thing with the input to your system, but no one builds an application entirely from the TCP layer up any longer. We all stand on the shoulders of someone else, and testing te entire stack is very valuable work. It's different from someone looking for a weakness to exploit to get sensitive data.

I'm fine with it deemed out of scope for the library. I bumped into this, saw that there was code in place making sure the header values fall in the latin-1 codespace, and thought this was an oversight and reported it.

I'm familiar with pen testing. I just think the default behaviour of a general purpose library should fall within spec and let Red Team tools explicitly opt-in to out of spec behaviour.

The problem is red teams already using it in that way will probably be surprised by this and in the current state of technology units, likely underfunded to do the work to fix things.  I'm not opposed to fixing this, but I want to be clear that it's not possible to do this fast and easy