Custom multipart/form-data Content-Type header silently discards file upload

Summary.

## Expected Result

```
{
  "args": {},
  "data": "",
  "files": {
    "logo": "data:image/jpeg;base64,<base64 image data>"
  },
  "form": {},
  "headers": {
    "Accept": "application/json",
    "Accept-Encoding": "gzip, deflate",
    "Connection": "close",
    "Content-Length": "154247",
    "Content-Type": "multipart/form-data; boundary=------------------------<some boundary>",
    "Host": "httpbin.org",
    "User-Agent": "python-requests/2.18.4"
  },
  "json": null,
  "url": "https://httpbin.org/post"
}
```

## Actual Result
```
{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "application/json",
    "Accept-Encoding": "gzip, deflate",
    "Connection": "close",
    "Content-Length": "154247",
    "Content-Type": "multipart/form-data",
    "Host": "httpbin.org",
    "User-Agent": "python-requests/2.18.4"
  },
  "json": null,
  "url": "https://httpbin.org/post"
}
```

## Reproduction Steps

```python
import requests

headers = {
  'Content-Type': 'multipart/form-data',
  'Accept': 'application/json'
}

file = open('path_to_file.jpg', 'rb')
files = {"logo": file}

endpoint = "https://httpbin.org/post"
r = requests.post(endpoint, files=files, headers=headers)
print(r.json())
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.0"
  },
  "platform": {
    "release": "4.4.0-103-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "1000207f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}
```
---------------------------

Reading some previous issues regarding multi-part file upload, I see that the usual response is something along the lines of "don't specify that header, requests will add it just fine". That's true, and currently works just fine on the user end, *if they realise that's the problem*, *if the docs they are using were tested even slightly instead of just copy-pasted from other clients* (e.g. curl, which handles this fine). 

But isn't this a case that requests can handle just fine on its own, 100% correctly? It doesn't seem to me that silently failing to upload any file at all is the correct response here. Even throwing an exception or a warning would be preferable. 

Note also that the Content-Length header lists the length correctly in both cases (with or without the custom header), but with the custom header requests fails to upload anything (presumably because it can't or won't set a boundary).

More specifically, what would break if [this](https://github.com/requests/requests/blob/master/requests/models.py#L508): 

```python
    if content_type and ('content-type' not in self.headers):
        self.headers['Content-Type'] = content_type
```

were changed to this:

```python
    if content_type and ('content-type' not in self.headers
            or self.headers['content-type'].lower() == 'multipart/form-upload'):
        self.headers['Content-Type'] = content_type
```

Hi @wlerin, we're simply passing through the custom header you've chosen to give us rather than making assumptions. Without a boundary, it won't successfully transfer the file, and that's expected. I'm a bit confused on what you're trying to achieve or what issues you have with the documentation.

We provide the ability to specify a Content-Type for each file if you wish to provide more specificity than `application/octet-stream`. That's bundled as part of your `files` object, not the request headers, as noted in the docs [here](http://docs.python-requests.org/en/master/user/quickstart/#post-a-multipart-encoded-file). I see that curl will automatically append the boundary to the header you provide, but I'm unsure that's a feature so much as an implementation detail.

If we were to change it, we'd likely want to make a change in urllib3 [here](https://github.com/shazow/urllib3/blob/69f16a0c555316f486f8d43d889edb1abae1e151/urllib3/filepost.py#L99). I'd still like to better understand the use case though before we go through that.

**Edit:** Just as a quick note, the [requests toolbelt](https://github.com/requests/toolbelt) has a lot of useful multipart stuff if you're trying to do things with other multipart encodings.

The docs causing the issue are the [mod.io](https://docs.mod.io/?python#add-game-media) ones. Aside from the glaring omission of the actual files (they're not very good docs), they also suggest adding a custom Content-Type header, which as mentioned causes requests to fail.

Other than that I have no need to specify the Content-Type header, but after spending far too long trying to figure out what the problem was, I'm not sure why requests (or urllib3) doesn't handle this case better, perhaps by appending a boundary as cURL does when none is provided and the Content-Type is compatible.

Calculating the Content-Length but then not sending anything seems like the wrong thing to do.

@wlerin we document this pretty vividly (i.e., if you set Content-Type headers without knowing what you're doing, you're in for pain because we won't override your preference and we can't read your mind). There are tools that give you more power, but in general, the existing API has worked rather well. In the past we tried to do as you suggest, but it ended up breaking more people than it helped. In short, there's no way to please everyone and trying to presume we know what you're doing ends up breaking more things than it fixes.

@sigmavirus24 I'm not sure I would call not mentioning a serious potential issue at all, anywhere, ever, in either the Requests or Urllib3 docs (or docstrings) "documenting it vividly". The only related documentation in either project is urllib3 explicitly stating that the Content-Type header *will* be [overwritten in this case](https://urllib3.readthedocs.io/en/latest/reference/index.html#urllib3.request.RequestMethods.request_encode_body)). Requests bypasses this.

That said, looking at the [actual implementation](https://github.com/shazow/urllib3/blob/c4f123dcdcad3582561373278d2772f819ec3cb8/urllib3/request.py#L145) of `request_encode_body`, I don't think it actually does what the docstring claims.

@nateprewitt You don't need to change anything in urllib3.filepost, it already returns the correct Content-Type header. Requests ignores it.