Make chardet an optional dependency

It has a serious performance hit and it'd be nice if it was easier to disable than:

```
if not response.encoding:
    response.encoding = 'utf-8'
```

I can't stress "serious" enough in the performance hit here. It was enough to cripple the entirety of Sentry's worker cluster which is way under utilization most of the time.


The easiest way to disable it would be to disable the package entirely in your infrastructure. This could be done by monkeying about with `sys.modules`, monkeypatching directly, or by providing another package called chardet that is just a no-op.

The best we're likely to get to an 'official' API for this is to adjust the `Response` factory in the `HTTPAdapter` to allow the user to specify a `Response` subclass. We're not going to want to have chardet need to be explicitly enabled, because that feature is optimised for the unaware user, not the aware one.

I take it you _do_ want to take advantage of our parsing of the headers to determine a text encoding, which is why you aren't unconditional here.

I think what I'm interested in knowing is whether you have a proposal API for allowing chardet to stay enabled in the default use case, but give you a nice hook to disable it.


Definitely having a simply way to override the Response would be helpful. I dont know about others, but as our use cases are generally more optimized and less care-free, we're generally willing to go a little bit farther in implementation.

Feel free to close this if it makes sense.

That said, it might still be worth noting the performance implications of chardet:

https://www.dropbox.com/s/mwb4z795a50ugfz/Screenshot%202015-04-22%2012.51.20.png?dl=0


So we should be clear about what requests' priorities are. Speed is great, but we will always put in more helpful features at the cost of speed. Always.

I am totally up for having a way to disabling chardet, but the API really does need to be clean. Otherwise, I feel like the patch above is really the nicest way to do it. Two lines isn't so costly!


No one should ever be patching sys.modules like you're suggesting. That's the reason most Ruby code is so unmaintainable. It also would completely prevent using chardet in any other library that may actually 100% require it. It'd be much safer to monkey patch Requests, which is also something you wouldn't want people doing.

Anyways, if this were something like "its 20% slower with chardet" I wouldn't care. This is more like "its 1000%+ slower with chardet" and that has some pretty legitimate consequences for the unaware.


To be clear, I didn't mean the monkeypatch, I meant these two lines:

``` python
if not response.encoding:
    response.encoding = 'utf-8'
```

There's another way to avoid this cost: don't use `Response.text`.

I don't deny that the use of chardet can, in some cases, be much slower than not using chardet. If it was hard to disable chardet I'd be more worried. However, it's not a difficult feature to disable, and you've clearly discovered how to do exactly that.

Like I said: if there's an obvious easier API I'm open to having it enabled. I'd also be open to extending the API documentation around `Response.text` to include an admonition that `chardet` can be very slow. However, I continue to believe that there's more value in leaving chardet in place than there would be removing it by default.


So if you're using a session, then you can use that two line fix with a session hook that will get registered for each response, e.g., 

``` py
def force_utf8(response, *args, **kwargs):
    if not response.encoding:
        response.encoding = 'utf-8'

s = requests.Session()
s.hooks['response'].append(force_utf8)
```


Also, chardet is working on fixing these issues. If you'd like to see them fixed faster you too can help @dcramer