Test socket server

Fixes #2866.
### What is this?

This is an implementation of a basic socket server that is able to run concurrently with the main thread. This might be useful for testing our 'Transfer-Encoding: chunked' functionality as pytest-httpbin isn't able to handle this kind of encoding.
### How does it work?

You provide the Server constructor with a handler that will be called once the socket server is listening. This handler will be able to accept clients and send and receive any info it wants to. The main thread will be able to query the server by creating a normal socket. 
### Syntax proposed

I think that using a Context-Manager is a great way of making it easy to use the Server. 

``` python
with Server(handler) as host, port:
    sock = socket.socket()
    sock.connect((host, port))
   ...
```
### Doubts
- urllib3 tries to use a IPv6 socket and falls back to IPv4 when it can't. Should I try doing the same thing?
- I made a new directory for dummyserver, but don't know whether that was the right thing to do.
- I am not sure whether I'm testing my code properly. Code is being tested in very different ways in `test_requests.py`
### Roadmap
- Handle exceptions in Server.
- Add features such as `basic_response_handler` in urllib3's implementation.
- Implement more tests
- Implement 'Transfer-Encoding: chunked' tests using the dummy server.

Is this a good idea? Or should I stop doing this right now?


Can we perhaps not call it dummyserver? Maybe something more accurate, e.g., testserver?


Calling it a testserver feels like a good idea. As to the approach, this is definitely going in the right general direction, at least as far as I'm concerned. Obviously you need to replace the test that's currently there with one that actually tests requests itself, but that's fine.

We also need to be on the lookout for flaky tests here. Threaded tests can get tricky.


Ok, I'll call it testserver.

The test I added is there just for testing the server. It might be weird to add tests for a testing utility but I think it is necessary as it could be broken in many no trivial ways. If you don't like having requests tests and testserver tests in the same file (which actually looks bad) we could do the following things:
- Having a separate file for testing testserver
- Extracting testserver as a separate package and developing it with its tests independently from requests
- Not testing it at all


I think I broke the CI server with tests that hang forever. I don't know whether I should do anything to fix that


Yup, that seems right. They don't consistently hang, but they do sometimes hang. Are you able to run the tests locally @BraulioVM?


PS @sigmavirus24 I don't seem to be able to stop the builds: can you do it?


I cannot stop the tests.


Well...that's not ideal.


@Lukasa I ran the tests locally on python2.7 and know why they hang. I have run the tests for the last version both on 2.7 and 3.4, and they are fine. Is there any easy way to replicate the build environment of the CI server? 

I am sorry for breaking it, I never thought there wasn't going to be a timeout or something like that.


Ok, I already have a failing test for chunked uploads (in python3, the 'Transfer-Encoding' header is not being set and python2.7 doesn't even let me use a generator as `data`)


Do you like the overall direction of this PR? Do you think I have gone too far? As I am new with this project I'm not sure whether this is the way to go


I think in general it's ok, but I need to spend some time playing with it tomorrow. 


@BraulioVM So, that test doesn't fail for me, it passes, but more importantly it does run!

Having played with this quickly on my local machine, this seems generally good: the test runs, the structure of the function mostly seems to be good, so I'm happy to have this as the basis of a set of more specific tests. I would like us to add some more helpers, but we don't need to do that right now: we can definitely tackle it later.

Well done @BraulioVM! Did you have more work you wanted to do before you proposed this for merging?


Thank you @Lukasa! I am happy this is finally going to be useful. 

I don't mind adding those helpers you talk about, but as I am not totally sure about how this server will be used I don't know what helpers should be implemented. I guess some logic for parsing the chunked content must be implemented in order to fully test the library, however, I don't think that logic should be built into TestServer.

There's no more work I was planning on doing. I was hoping you would tell some other things you wanted this PR to have (such as those helpers).


So, some helpers that might be useful:
- something that lets you easily return a complete response from a HTTP/1.1 string.
- something that returns 200 OK but saves the request off to be examined

Ideally we'd want these with tests that use them, to confirm they work.


Ok! Sure, everything I implement will be tested. 

Just for clarification, when you say "return a complete response from a HTTP/1.1 string" you mean the _string_ contains the http headers and the body of the response and not just its body, right? Or is it just the body?


That's correct, headers and body. =)


Ok, done!

I added an attribute to the TestServer class called `handler_results`. It is a list which stores the return values of the request handler. This allows the server instance returned by  `text_response_server` to store the requests by returning their content.

I have added tests for those two features as well.


Anything else I should do in order to get this merged?


Not right now @BraulioVM, we're pretty quiet over the holiday period so we probably won't find time to focus on reviewing this until the new year.


Ok, that's perfect!

Happy holydays!


I have just finished my exams and have time to work on this again if it is heading the right direction. I have read https://github.com/kennethreitz/requests/issues/2866 and believe you want something similar to this, but you may prefer a different implementation anyway.

Should I keep working on this or look for another issue to work on?


I believe this is generally going in the right direction, but now that @kennethreitz is more active he may want to see if this is something he wants. @sigmavirus24 and I are definitely :+1: on this for improving our testing, but it's up to Kenneth.


Ok, I'll wait to see what Kenneth thinks of this


I have no opinion :)


Ok, I'll give this a review tomorrow and see where we are.


Ok @BraulioVM I've left some notes in the diff. =)

Unfortunately, while you've been away we moved the tests to a `test` subdirectory, so you'll need to move this change onto that directory structure. Sorry!


Ok, I have had several doubts while merging with master:
- I have put `TestTestServer` test cases inside `test_util.py` because that's the file I've found  best for it. Should I change it? I had to import requests in order to test the server, but I believe you did not import it on purpose.
- Is there any better place for `test_chunked_upload`?


Ok, we're making some good progress here @BraulioVM! We'll have a few more rounds of code review while we get this stuff settled, and right now our Jenkins runs are hanging (I'll investigate why).

Did you lose `test_chunked_upload` entirely? It doesn't seem to be in the diff at all: commit f17ef753d2c1f4db0d7f5aec51261da1db20d611 just removed it, without moving it _to_ anywhere.


I'm sorry for needing this much reviewing. I hope that I can get the code right from the beginning with my next PR.