Fixing max_retries to accept Retry instance

adapters. HTTPAdapter max_retries parameter specifies that you can pass an instance of the Retry class directly to it.  

>     :param max_retries: The maximum number of retries each connection
>         should attempt. Note, this applies only to failed DNS lookups, socket
>         connections and connection timeouts, never to requests where data has
>         made it to the server. By default, Requests does not retry failed
>         connections. If you need granular control over the conditions under
>         which we retry a request, import urllib3's ``Retry`` class and pass
>         that instead.

However, lines 114-116 of the code will instead put instance of the Retry class into a parameter of the Retry.from_int() function.  The result is, once invoked during a retry, this error chain occurs:

>   File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 469, in get
>     return self.request('GET', url, **kwargs)
>   File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 457, in request
>     resp = self.send(prep, **send_kwargs)
>   File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 569, in send
>     r = adapter.send(request, **kwargs)
>   File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 362, in send
>     timeout=timeout
>   File "/usr/lib/python2.7/dist-packages/urllib3/connectionpool.py", line 559, in urlopen
>     _pool=self, _stacktrace=stacktrace)
>   File "/usr/lib/python2.7/dist-packages/urllib3/util/retry.py", line 227, in increment
>     total -= 1
> TypeError: unsupported operand type(s) for -=: 'Retry' and 'int'

This patch checks to see if max_retries is an int before passing it to Retry.from_int().  That way, if max_retries is already an instance of Retry, it will be left intact and function as documented.

Some cursory searches for the above TypeError indicate that this has been an undiagnosed problem across the net for quite a while.

Cheers!

Thanks for this! Can we get a test for this so it won't be regressed. :)

Strangely, test_requests.py already has a test for this.  I can't figure out why it was passing:

```
def test_urllib3_retries(httpbin):
    from urllib3.util import Retry
    s = requests.Session()
    s.mount('http://', HTTPAdapter(max_retries=Retry(
        total=2, status_forcelist=[500]
    )))

    with pytest.raises(RetryError):
        s.get(httpbin('status/500'))
```

It seems like, prior to my patch, that should have also manifested the TypeError: that I'm seeing.  I'm not well versed in pytest though.

@phreakmonkey urllib3’s implementation of Retry has [a branch in `from_int()`](https://github.com/shazow/urllib3/blob/67591cdfd3f29f168baa05cc1fcc1fc92c7e9deb/urllib3/util/retry.py#L195) specifically for handling a Retry object. Could you please provide some more info of how you encountered this, a minimum viable reproduction, and the output of ’python -m requests.help`?

My hunch is either you have an older version of urllib3 or that something was changed in urllib3’s semi-recent retry work that is causing it to no longer behave as expected.

Oh interesting.  This is what I get for using the OS distributions of libraries.   The system where I encountered the error is Raspbian 8 on a Raspberry Pi 3:

```
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
```

```
$ pip show requests
---
Name: requests
Version: 2.4.3
Location: /usr/lib/python2.7/dist-packages
Requires:

$ pip show urllib3
---
Name: urllib3
Version: 1.9.1
Location: /usr/lib/python2.7/dist-packages
Requires:
```

So, yeah, outdated OS-included libraries are likely the culprit.  That's what I get for thinking "oh, it's just a Raspberry Pi.  No need to set up pyenv and virtualenv for a few automation scripts..."

Whelp, carry on!


Yep, 2.4.3 is over 3 years old and likely won’t behave with our current documentation. Glad you got it sorted!

On top of that, the "undiagnosed issue" you reference has been diagnosed as several different causes. One of which is that Requests (when installed from PyPI) used to vendor urllib3 and people used to separately install urllib3 in spite of our documentation so there were two different sources of the Retry object.