Invalid file object with requests >= 2.13.0 on Jython

I'm running into a repeatable error when testing [omniconf](https://github.com/cyso/omniconf/tree/1.1.1) on Jython with requests >= 2.13.0:

```
======================================================================
1) ERROR: test suite for <class 'omniconf.tests.backends.test_vault.TestVaultBackend'>
----------------------------------------------------------------------
   Traceback (most recent call last):
    .tox/jython/Lib/site-packages/nose/suite.py line 209 in run
      self.setUp()
    .tox/jython/Lib/site-packages/nose/suite.py line 292 in setUp
      self.setupContext(ancestor)
    .tox/jython/Lib/site-packages/nose/suite.py line 315 in setupContext
      try_run(context, names)
    .tox/jython/Lib/site-packages/nose/util.py line 471 in try_run
      return func()
    omniconf/tests/backends/test_vault.py line 87 in setUpClass
      cls.manager.initialize()
    .tox/jython/Lib/site-packages/hvac/tests/util.py line 44 in initialize
      assert not self.client.is_initialized()
    .tox/jython/Lib/site-packages/hvac/v1/__init__.py line 92 in is_initialized
      return self._get('/v1/sys/init').json()['initialized']
    .tox/jython/Lib/site-packages/hvac/v1/__init__.py line 944 in _get
      return self.__request('get', url, **kwargs)
    .tox/jython/Lib/site-packages/hvac/v1/__init__.py line 971 in _Client__request
      response = self.session.request(method, url, headers=headers,
    .tox/jython/Lib/site-packages/requests/sessions.py line 488 in request
      resp = self.send(prep, **send_kwargs)
    .tox/jython/Lib/site-packages/requests/sessions.py line 609 in send
      r = adapter.send(request, **kwargs)
    .tox/jython/Lib/site-packages/requests/adapters.py line 413 in send
      resp = conn.urlopen(
    .tox/jython/Lib/site-packages/requests/adapters.py line 413 in send
      resp = conn.urlopen(
    .tox/jython/Lib/site-packages/requests/packages/urllib3/connectionpool.py line 588 in urlopen
      conn = self._get_conn(timeout=pool_timeout)
    .tox/jython/Lib/site-packages/requests/packages/urllib3/connectionpool.py line 588 in urlopen
      conn = self._get_conn(timeout=pool_timeout)
    .tox/jython/Lib/site-packages/requests/packages/urllib3/connectionpool.py line 241 in _get_conn
      if conn and is_connection_dropped(conn):
    .tox/jython/Lib/site-packages/requests/packages/urllib3/util/connection.py line 27 in is_connection_dropped
      return bool(wait_for_read(sock, timeout=0.0))
    .tox/jython/Lib/site-packages/requests/packages/urllib3/util/connection.py line 27 in is_connection_dropped
      return bool(wait_for_read(sock, timeout=0.0))
    .tox/jython/Lib/site-packages/requests/packages/urllib3/util/wait.py line 33 in wait_for_read
      return _wait_for_io_events(socks, EVENT_READ, timeout)
    .tox/jython/Lib/site-packages/requests/packages/urllib3/util/wait.py line 24 in _wait_for_io_events
      selector.register(sock, events)
    .tox/jython/Lib/site-packages/requests/packages/urllib3/util/selectors.py line 314 in register
      key = super(PollSelector, self).register(fileobj, events, data)
    .tox/jython/Lib/site-packages/requests/packages/urllib3/util/selectors.py line 179 in register
      key = SelectorKey(fileobj, self._fileobj_lookup(fileobj), events, data)
    .tox/jython/Lib/site-packages/requests/packages/urllib3/util/selectors.py line 163 in _fileobj_lookup
      return _fileobj_to_fd(fileobj)
    .tox/jython/Lib/site-packages/requests/packages/urllib3/util/selectors.py line 47 in _fileobj_to_fd
      raise ValueError("Invalid file object: {0!r}".format(fileobj))
   ValueError: Invalid file object: <_socket._socketobject object at 0x1cc>
   -------------------- >> begin captured logging << --------------------
   requests.packages.urllib3.connectionpool: DEBUG: Starting new HTTP connection (1): localhost
   requests.packages.urllib3.connectionpool: DEBUG: http://localhost:18200 "GET /v1/sys/init HTTP/1.1" 200 22
   --------------------- >> end captured logging << ---------------------
```

My test [initializes hvac](https://github.com/cyso/omniconf/blob/1.1.1/omniconf/tests/backends/test_vault.py#L78), which in turn checks if the requests client [is already initialized](https://github.com/ianunruh/hvac/blob/v0.2.17/hvac/v1/__init__.py#L92). This seems to do a GET request, but when [opening the response](https://github.com/kennethreitz/requests/blob/v2.13.0/requests/packages/urllib3/util/selectors.py#L45), the resulting file object is reported as being invalid.

I can reproduce this error when running omniconf tests with `tox -e jython`, after installing Jython and Hashicorp Vault (see the [.travis-ci.yml](https://github.com/cyso/omniconf/blob/1.1.1/.travis.yml#L34) for steps).

Older versions of requests work fine, specifically when specifying `requests < 1.12.0` (because of the earlier issues with `Method code too large!`).

This seems extremely likely to be related to the use of selector objects in Python. This error is raised when we attempt to call the `fileno` method on the socket object, so that we can wait on it. Can you confirm that this simply doesn't work on Jython?

Ah, nevermind, I can:

```python
>>> import socket
>>> s = socket.socket()
>>> s.fileno()
<_realsocket at 0x2 type=unknown open_count=1 channel=None timeout=None>
>>> int(s.fileno())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int() argument must be a string or a number, not '<_realsocket at 0x2 type=unknown open_count=1 channel=None timeout=None>'
```

So I'm pretty sure this is Jython just doing exactly the wrong thing. The [CPython documentation makes it very clear](https://docs.python.org/2.7/library/socket.html#socket.socket.fileno) that `socket.fileno` should return a small integer, which it does not on Jython. I'm not really sure what Jython is up to here, but it doesn't look at all right.

Can we get a Jython developer to weigh in on how we're supposed to use selectors with Jython?

I won't be much use for you there unfortunately, except for testing fixes. The [Jython docs](http://www.jython.org/docs/library/select.html) do have a section on it, and the language seems to imply that `file.fileno` or `socket.fileno` should be usable.

This bug on Jython might also be related: http://bugs.jython.org/issue2320

I think you probably need to report this to the Jython devs directly: the result just seems incorrect and inconsistent with their docs.

What has changed between 2.12.x and 2.13.x in relation to selectors in `requests`? It seems to have worked fine before on Jython.

We started using them. =)

Historically we had only ever used `select`, directly on socket objects. That's not so efficient, and limits us in high-concurrency situations, so we moved to allowing different kinds of selector by embracing the abstraction used in Python 3's `selectors` module via a backport. That was the change you saw here.

cc @jimbaker

I'm surprised it took so long for this issue to be noticed if Jython has been returning non-integers from `socket.socket.fileno()`.

So actually it looks like this is both documented and intended behavior? https://wiki.python.org/jython/NewSocketModule#socket.fileno.28.29_does_not_return_an_integer

Meaning `urllib3` shouldn't be using anything except `select.select` on Jython even if all the other selectors are available. That'll necessitate a PR.

I'll download Jython tonight and see if I can get something with minimal changes to `urllib3/util/selectors.py` working.

To make matters worse the current implementation of `BaseSelector` relies heavily on getting back something hashable to identify `SeelectorKeys` by (ie `fileno`) so I may have to move to a subclass of `BaseSelector` that uses `select.select` and is Jython specific.

I uninstalled requests. 
# /usr/local/jython/bin/jython /usr/local/jython/pip uninstall requests 
and download request 2.7.0 source code. (requests-2.7.0.tar.gz) 
# /usr/local/jython/bin/jython setup.py install 
it is no necessary to reinstall your package (my case is pysolr )

This is ultimately an issue with Jython deviating from the file object spec laid out by Python. If we are eventually able to resolve this is will need to happen at the urllib3 layer rather than Requests.