Document requirements for SNI support on Python2

Adds a section to Request's advanced usage guide on what Server Name
Indication is, its purpose, and how to enable it on Python2.


Thanks for this!

However, I'm on the fence. So far we've made a conscious decision not to _officially_ document this support in Requests, because we don't adequately test it. We don't have an SNI environment in our CI system, we've regressed this support in the past and we'll probably do it again.

We should combine that with the fact that Requests is meant to be _for humans_. This SNI support is a frankly-fairly-ugly workaround for a serious failing in Python 2. I'm happy to suggest this as a workaround for people everywhere else on the internet (and I do), but I'm reluctant to add it to the core documentation.

However, if the rest of the team wants to I'm happy to let them, so I'll leave this open until @kennethreitz and @sigmavirus24 take a look.


Would any number of caveats, warnings, or flashing red text indicating the tenuous level of support convince you otherwise? ;-)

For humans, receiving an error message like:

```
requests.exceptions.SSLError: hostname 'haveibeenpwned.com' doesn't match either of '*.azurewebsites.net', '*.scm.azurewebsites.net', '*.azure-mobile.net', '*.scm.azure-mobile.net'
```

Can be pretty daunting if you're not familiar with some of the more esoteric aspects of SSL. And frustrating if you are. Even if the actual _hack_ is not described within the Requests documentation, what about documenting this variation between Python2 an 3 support and (possibly) pointing to external information?

The most likely alternatives (as I see them) for humans encountering this error is to:
- Give up on using SSL.
- Disable host name verification.
  Neither of these are particularly desirable outcomes. Including some coverage of SNI in the documentation may help to avoid these.


Hmm.

I wonder if what we actually need is an FAQ or help section, which could then contain something a bit more like this:

#### Help! What's this "hostname doesn't match" error mean and how do I fix it?

Some brief discussion about SNI and hostname verification.


That's a very good idea. (At least in my opinion)

To where should a FAQ entry direct the reader for further information? Unfortunately the current [urllib3 documentation for SNI](http://urllib3.readthedocs.org/en/latest/contrib.html#sni-support-for-python-2) is empty. I'd be very happy to write a FAQ entry once I have a better understanding of what does and doesn't belong in the main Requests docs. :-)

I did find [this blog entry](http://ibofobi.dk/blog/archive/2013/03/sni-support-for-requests/) on SNI support in Requests, but it was written before Requests would optimistically attempt to enable it.


I'm actually quite enamoured by the idea of having an FAQ section. I think there's a bit too much in the Advanced docs that is really documenting some weird edge case behaviour.

I'll take a look at this at some point fairly soon: it'd be nice to break the advanced docs down a little bit (they're huge!).

My canonical SNI reference is [this Stack Overflow answer](https://stackoverflow.com/questions/18578439/using-requests-with-tls-doesnt-give-sni-support/18579484#18579484).


Excellent, I'll update this pull request to move documentation to the FAQ, referring to the Stack Overflow answer details on enabling Python2 support rather than including it locally.


I've updated this pull request, removing the new section from the advanced docs and adding a new question to the FAQ.


Awesome, that's a good start.

I think we want to move the fact that this answer applies only to Python 2.X earlier in that section. Talking at length about Requests' lack of SNI support before saying "actually it's fine in 3.X" is a bit sad (and makes us look bad!). Maybe the first paragraph could be:

> These errors occur when :ref:`SSL certificate verification <verification>` fails to match the certificate the server responds with to the hostname Requests thinks it's contacting. If you're certain the server's SSL setup is correct (for example, because you can visit the site with your browser) and you're using Python 2.6 or 2.7, a possible explanation is that you need SNI support.

Thoughts?


I certainly had no intent of making Requests look bad. ;-)

I've adjusted that first paragraph accordingly. I also like mentioning the
Python2 restriction early as it helps the reader diagnose more quickly if
this issue could be affecting them.


Excellent, I'm happy with that.

Normally I'd merge documentation changes myself, but this changes the layout a little bit and I want to chat with @kennethreitz a bit before we go ahead and merge. It will definitely get merged though. =D


Looks good! We can always refactor later.