Malformed `Set-Cookie` containing CRLF does not cause an error

After receiving a malformed `Set-Cookie` header containing a CRLF, a malformed `Cookie` header is generated (still containing that CRLF).

## Expected Result

Per https://github.com/requests/requests/issues/3521, expect an exception to be raised, rather than generating invalid HTTP.

## Actual Result

An invalid Cookie header was generated containing a CRLF character.

## Reproduction Steps

... Can't quite figure out a concise repro. Here's the bogus cookie (extracted from the raw HTTP text):

```
...
Set-Cookie: ___utmvbtouVBFmB=gZg
    XbNOjalT: Lte; path=/; Max-Age=900
...
```

Gives: 

```
Cookie: ___utmvbtouVBFmB=gZg\r\n    XbNOjalT: Lte; <other-cookies>
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "1.7.1"
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.5.4"
  },
  "platform": {
    "release": "15.6.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "100020af",
    "version": "16.2.0"
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "100020ef"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": true
}
```

Hey @paultiplady, thanks for bringing this to our attention. The issue you're referring to is about #3366 which was to prevent users from creating requests with headers that contained newlines. While we do prevent that now, we don't validate headers received from servers.

Putting together a [quick repro](https://gist.github.com/nateprewitt/44242c7e4b2f7758db3bde995397d231), we actually don't parse multiple header issues in Requests. This one is specifically called out in [RFC 7230 3.2.4](https://tools.ietf.org/html/rfc7230#section-3.2.4) though:

>A user agent that receives an obs-fold in a response message that is
   not within a message/http container MUST replace each received
   obs-fold with one or more SP octets prior to interpreting the field
   value.


We do seem to mutate a bit by replacing `\r\n` with a single `\n` and replacing multiple spaces with a single but that's still not right. So I think the question now is where should this be handled? Does urllib3 need to be doing more validation on what it's receiving from httplib, or should be take on that burden in Requests?

I'd raise this issue in urllib3, this could be something we can't handle though without v2 if it's at the httplib level.

Done, thanks for the steer & quick repro folks.

👍 Thanks for bringing it to our attention and driving it, @paultiplady. @SethMichaelLarson, let me know if you need anything from our end or want a second pair of eyes.

After talking the issue over in urllib3, it appears they have handling for the return character on the master branch. I've tried a few times to verify it works in Requests but haven't been able to fix the issue yet. I was able to create a urllib3 test to verify it's working at that level.

We need to look into what's happening between us getting the connection object back from urllib3 and when we're creating the cookie.

Hello @nateprewitt ! :)

I encounter the bug as well, maybe I can help to fix it with a little help ! I guess the error should be raised at:
https://github.com/requests/requests/blob/master/requests/adapters.py#L484 ?

I tested your repro with the latest version of urllib3 (1.24.1) and requests (2.21.0) and the invalid header is still accepted so I'm unsure urllib3 pushed the fix (for the newline) to the stable version yet, I will check with them !

This has been opened as an issue on the urllib3 project, so let's focus there.