Adding an argument to the adapter for passing a block argument 

Adding an argument to the adapter for passing a block argument to the connection pool.

This allows for blocking when using threading to prevent the pool from creating more connections that the max-size allows.

Specifically was seeing the following warnings were shown when using threads to download files without the block=True:

```
WARNING:requests.packages.urllib3.connectionpool:HttpConnectionPool is full, discarding connection: www.example.com
```


Thanks @sigmavirus24 for the help!

This was causing problems when I was doing threaded gets to a single host. I can get around it by subclassing the adapter and overriding the creation of the connection pool (where I ran into the problem from #1357), but this seems like it should be something you can do without needing to sub class the adapter.


Yeah I agree you shouldn't need to sub-class the adapter. So that definitely pushes me over to :+1:... once we decide how to fix the tests. :)


Oh that's my bad, I should have warned you to add `'_pool_block'` to the list of `__attrs__` on L66. That'll fix this.


Thanks, I have updated with the correct list of attrs.


:cake: Awesome! Sorry it took so long, but this pull request now looks perfect IMO. Hopefully @Lukasa will agree.


I think this PR is in great shape, but for reasons that are nothing to do with the code I'm slightly more lukewarm to it than @sigmavirus24 is. I consider subclassing the Transport Adapter to be a legitimate part of Requests' API: the documentation talks about it, some interfaces require it, etc. etc.

With that said, I'm +0.5 on this. I think it'd be a good addition to the library and it doesn't look like it'll break anything, but I don't think there is anything wrong with subclassing the adapter either. On balance I'd rather take it than leave it. That said, I don't want adding arguments to the constructor of the adapter to become a trend. =P


@Lukasa but sub-classing the adapter just to rewrite one (or two methods) to include an extra parameter seems a bit like over-kill to me. There are times when subclassing is appropriate and times when it isn't.

We may be better off doing something else though:

What if we rewrite `HTTPAdapter` to be more intelligent. We'll modify the `__init__` method to take `**kwargs` that are meant only for the `poolmanager` initialization, so something like:

``` python
class HTTPAdapter(BaseAdapter):
    __attrs__ = ['max_retries', 'config', '_pool_connections', '_pool_maxsize', '_pool_kwargs']
    def __init__(self, pool_connections=DEFAULT_POOLSIZE,
                 pool_maxsize=DEFAULT_POOLSIZE, max_retries=DEFAULT_RETRIES,
                 **kwargs):
        self.max_retries = max_retries
        self._pool_kwargs = kwargs
        self._pool_connections = pool_connections
        self._pool_maxsize = pool_maxsize

        self.init_poolmanager()

    # ...

    def init_poolmanager(self):
        self.poolmanager = PoolManager(
            num_pools=self._pool_connections, maxsize=self._pool_maxsize,
            **self._pool_kwargs
        )
```

Because really we have never used `self.config` on the `HTTPAdapter`, nor have we ever really needed to set `_pool_connections` or `_pool_maxsize` twice (which we do both in `__init__` and `__setstate__`). `init_poolmanager` really doesn't need parameters to work well.