urllib3 connection pool block is not properly implemented

Current connection pooling in the urllib3 package is not making a proper use of the `block` parameter, and is not using `pool_timeout` for anything.

In the current implementation of the [`_get_conn` method](https://github.com/kennethreitz/requests/blob/362da46e9a46da6e86e1907f03014384ab210151/requests/packages/urllib3/connectionpool.py#L219), if `block` is `False` and the pool raises an `Empty` indicating that there are no connections left because all are being used, a new connection is created anyway an later on discarded.

Instead of this, the connection attempt should be cancelled with an Exception being raised. Or, at least, there should be the option to indicate that this is the expected behaviour. Otherwise, there is no way to make use of the connection pooling to effectively limit the amount of concurrent outgoing connections without getting the additional ones stuck waiting.

Also, pool_timeout is currently getting the default `None` value and there is no way to change it.
It should be possible to define it when the adapter is created, like the rest of the parameters, to indicate how long a connection attempt can be left waiting in the queue.

If the suggested changes are discussed and accepted I can implement them.

> Instead of this, the connection attempt should be cancelled with an Exception being raised.
> 
> Otherwise, connection pooling provides not benefit.

That is not true.

The connection pooling strategy requests uses is what is known as a "leaky bucket". Essentially, by default, Requests will store as many connections as it can in the pool. However, if the user is making more concurrent requests than the size of the pool, they will not by default be forced to wait for a new connection to show up: they are instead given a brand new one. If and when all connections are returned to the pool, the excess connections used are thrown away.

This means that in the default case Requests provides a maximum threshold on how much state it will maintain for the sake of connection pooling, whilst still allowing users to burst over that threshold temporarily. This is a very common connection pooling strategy, which is why it is the default for both Requests and urllib3.

Connection pooling still provides a substantial benefit, because we still keep many connections around. In a single-threaded case, for example, where each response is entirely read before making a new request, only one connection per host will be opened. This is exactly as expected.

> Also, pool_timeout is currently getting the default `None` value and there is no way to change it.

I agree that this is a limitation that should be addressed. I would accept a PR that makes this a property on the HTTPAdapter that is automatically passed to `urlopen`/`get_conn` as appropriate.

Thanks for the quick response @Lukasa 

Please have a look again at the first comment, which I edited shortly after publishing.

Basically: Even if I we discussed and agreed on the inconvenience of the 'leaky bucket' strategy (which will probably not happen), it's clear that this would be a major functionality change and therefore it would make no sense to force its introduction.

However, I think that a parameter could be added to provide such a functionality. Otherwise, as I said, there is no way to actually limit the amount of outgoing connections without taking care of it in a higher level.

A parameter exists already: you can set `block` on the HTTPAdapter.

@Lukasa No, no, what I mean is something else.

I mean another parameter, call it `fail_if_empy` to indicate that, if `block` is `False` and the connection pool is empty, an Exception will be raised instead a new connection created.

Functionally, what I would like to achieve is being able to use the connection pool to make sure that the number of concurrent outgoing connections will never exceed a given number ( `pool_maxsize`)

@csala Right, but that is what the `block` parameter does. If you look at the code you'll see that `block`, if set to true, causes an `EmptyPoolError` exception to be raised rather than having a new connection created.

However, it should be noted that requests/urllib3 do not provide any limit on the *total* number of outgoing connections. They only provide tools to do *per-host* limits on the number of outgoing connections.

@Lukasa Well, that's not entirely true. Basically because that part of the code can never be reached because of how the queue works and because `pool_timeout` is not being used.

At the moment, if `block` is set to `True`, the `pool.get` call will never raise an exception because it will just block the `get` attempt indefinitely until a connection is available.

However, it's true that if the `pool_timeout` is indicated and reached, it would work as I expect. And it could even be set to 0 to make it fail immediately.

But, on the other side, without such a `fail_if_empty` parameter, you cannot have it following the 'leaky_bucket' strategy along with a timeout!
If there was this parameter, you could make it wait for some time and, if no connection was available after the given timeout, go on and create a new one, which currently is not possible.

@csala I'm in agreement that we should expose the pool timeout. I'm just not in agreement that we should add anything else. All of the relevant behaviours can be controlled by varying `block` and `pool_timeout`.

@Lukasa Alright, I'll go for that bit.

Fab, I'll be happy to review a PR adding that functionality. =)

In an effort to clean up the issue tracker to only have issues that are still relevant to the project we've done a quick pass and decided this issue may no longer be relevant for a variety of potential reasons, including:

* Applies to a much older version, unclear whether the issue still applies.
* Change requires a backwards incompatible release and it's unclear if the benefits are worth the migration effort from the community.
* There isn't a clear demand from the community on the change landing in Requests.

If you think the issue should remain open, please comment so below or open a new issue and link back to the original issue. Again, thank you for opening the issue and for the discussion, it's much appreciated.