Make Response.content() return None for an empty response

Fix #3698.

This fixes also a traceback in https://github.com/galaxyproject/bioblend/blob/master/bioblend/galaxy/client.py#L135 where the `text` attribute of an empty `requests.Response()` object is used:
```
Traceback (most recent call last):
  File "/usr/users/ga002/soranzon/software/galaxyproject_bioblend/tests/TestGalaxyInstance.py", line 37, in test_get_retry
    self.gi.libraries.get_libraries()
  File "/usr/users/ga002/soranzon/software/galaxyproject_bioblend/bioblend/galaxy/libraries/__init__.py", line 218, in get_libraries
    libraries = self._get(deleted=deleted)
  File "/usr/users/ga002/soranzon/software/galaxyproject_bioblend/bioblend/galaxy/client.py", line 135, in _get
    raise ConnectionError(msg, body=r.text,
  File "/usr/users/ga002/soranzon/software/galaxyproject_bioblend/.tox/py27/local/lib/python2.7/site-packages/requests/models.py", line 796, in text
    if not self.content:
  File "/usr/users/ga002/soranzon/software/galaxyproject_bioblend/.tox/py27/local/lib/python2.7/site-packages/requests/models.py", line 772, in content
    self._content = bytes().join(self.iter_content(CONTENT_CHUNK_SIZE)) or bytes()
  File "/usr/users/ga002/soranzon/software/galaxyproject_bioblend/.tox/py27/local/lib/python2.7/site-packages/requests/models.py", line 705, in generate
    chunk = self.raw.read(chunk_size)
AttributeError: 'NoneType' object has no attribute 'read'
```

Heh, I was going to say that we shouldn't tolerate silly status codes until I saw that we already tolerate `0`. That's really quite odd, but fair enough, I guess this is a logical extension of what we already do.

However, before we merge this, can I ask you to please add a test for this logic?

@Lukasa Do you mean a test that for an empty `requests.Response()` object, the `content` property is None?

Yep. =)

A couple of things here just for future readers. This unfortunately wouldn't fix the problem #3698 had because their mocking still required a valid status code in their empty response.

The other thing to think about is that with this patch, empty responses that used to work with valid bodies but no status code will now return `None`. Likely a rare edge case, but #3698 was thought to be unlikely too.

I remain really unsure that we should tolerate content with no status codes, but clearly we have done it before so... 😕 

I like the proposed logic. 

Just another passing thought, while we're here. If we're going to loosen this up, should we also broaden the check to `or self.raw is None` so we're solving #3698? Otherwise we still have an awkward failure mode in the event of a valid status_code but no response body.

Honestly, I really don't think we need to solve for #3698.

There's little in our documentation about creating custom Response objects and while Transport Adapters can do that, we don't document what they need to set. With that in mind, if someone's mocking out requests, they should probably be putting more effort into it than this Pull Request makes them. Why? Because that's not how we are expecting users to use the Response object. There are also *several* libraries for doing this, and if someone's using `mock` they can autospec a Response object.

In short, there's little value in this patch to the critical path of Requests.

> but clearly we have done it before so... 😕

I don't agree that because we've done something before we need to continue down that path. I especially feel we don't need to do this when we recognize that it was a mistake to do this previously.

@nateprewitt I'd be happy to change the test to:
```
if self.status_code == 0 or self.raw is None:
```
or anything that makes:
```
r = requests.Response()
r.content
```
return `None`. I think most programmers would expect this and that the traceback is a regression.

> I think most programmers would expect this and that the traceback is a regression.

Would most programmers expect this? I'm not sure that I would.

I think the reality here is that we have discovered that a concern originally raised in #3607 was correct: our defense against `response.raw` being `None` was there not so much because we needed it but because downstream libraries were patching our objects in such a way that `response.raw` was `None`.

From my perspective then, there are two sensible choices. Number one is to change this patch such that we tolerate the *actual problem*: namely, that `response.raw` is `None`. Number two is to decide that we simply don't support `response.raw` being `None`, and the error is exactly correct.

I think I'm leaning towards number one, if only because we've handled this kind of problem in the past (admittedly with an overbroad `except` block).

@Lukasa I'll try to explain why I think that this is the expected behaviour:

- `requests.Response` class is clearly part of the `requests` API and creating such objects is useful when dealing with connection exceptions
- the only `__init__` method of `requests.Response()` has no parameters
- using a property of a legitimately created object shouldn't raise an error, unless there is a very good reason

>  Number one is to change this patch such that we tolerate the actual problem: namely, that response.raw is None.

So, is
```
if self.status_code == 0 or self.raw is None:
```
a good solution for you?

> I think I'm leaning towards number one, if only because we've handled this kind of problem in the past (admittedly with an overbroad except block).

This makes sense to me. We can add the requirement that raw not be None in 3.0

@nsoranzo adding the explicit check for None works for me.

@sigmavirus24 I've added the explicit check for None and also a test as requested by @Lukasa.

The explicit check for `None` works. In an ideal world I'd rather change the logic to just check `raw` directly (presumably the status code `0` behaviour is meant to be a crutch for this), but I'd worry about regressing some other wacky edge case. So let's just accept that this is a mess and move on. =P

Arg, github had refreshed, but not quite enough. =(