Make chardet encoding auto-detect run once

When you are using reuqest.request to get large non-text files and you are trying to call r.text, it tries to auto-detect using chardet because there is no header defining the charset.

When chardet is running on large EXE/PDF files (and maybe other file types) it takes quite some time to get the answer, which is None.

Once None returns, self.encoding receives the None value. Therefore the next time you call r.text on the same content, it will try to auto-detect again as if you never tried to auto-detect it.

I know it doesn't make much sense to use r.text when requesting PDF/EXE files but sometimes websites do return EXE/PDF content and not HTML as you would expect.

I think it can also improve performance when doing multiple calls to r.text on text content that needs to be auto-detected as well.

Why prefer `r.text` over `r.content`? Why do you want binary data (exe, pdf) as unicode?

> Why prefer `r.text` over `r.content`? Why do you want binary data (exe, pdf) as unicode?

Thanks for the comment.

It is not a matter of preference as need. 
for example I build a crawler and at some point it's doing some text searches I need to get the right encoding.

Also, if I give the user option to input a website, I saw cases a domain redirect you to download PDF and in that case because of this behavior he spends some time until the chardet auto-detect it's not textual content

So why not use the `Content-Type` header to detect what you're receiving from the website and be more intelligent about your usecase?

> So why not use the `Content-Type` header to detect what you're receiving from the website and be more intelligent about your usecase?

In general you are right.
However, as much as I understand even in most cases it's true there are cases you won't get the Content-Type header.

If your comment is just about my usecase so again, you are right, I can count on the Content-Type header but I'll probably going to miss some data, moreover, the true story here I'm using another project that's doing that.

If your comment is about my pull-request I wasn't sure if this is something the maintainers here would like to do for the same reason I mention above.

In addition, I think it is a better practice even if the content is a textual file so the auto-detect won't get evaluated more than it should, once you have the result there is no reason to my opinion to auto-detect again.
Just to clarify, personally I saw the slowness in non-textual formats but it is possible the auto-detect will take some time on textual content as well.

To me, it seems that the logical meaning of the None value of self.encoding supposed to indicate we don't know the encoding was mixed with the self.encoding becomes None in a case chardet return and "decided" the encoding is None

So, this pull request breaks the correct behaviour of `r.text`. In the case where `r.encoding` is None, the first call to `r.text` will return properly encoded data. The second call will return something wholly different because it won't store the `apparent_encoding` anywhere. It's the wrong fix. If you want to move forward with this, i'd suggest a different approach of caching the detected encoding somewhere in `apparent_encoding` so each time you call that after the first, it doesn't keep using chardet