Fixes #5855 - HttpClient may not send queued requests.

[sbordet]

Changed the AbstractConnectionPool.acquire() logic to call tryCreate() even
when create=false.

This is necessary when e.g. a sender thread T2 with create=true steals a
connection whose creation was triggered by another sender thread T1.
In the old code, T2 did not trigger the creation of a connection, possibly
leaving a request queued.
In the new code, T2 would call tryCreate(queuedRequests), possibly triggering
the creation of a connection.

This change re-introduces the fact that when sending e.g. 20 requests
concurrently, 20+ connections may be created.

However, it is better to err on creating more than creating less and leaving
requests queued.

Signed-off-by: Simone Bordet simone.bordet@gmail.com

[sbordet]

@gregw @lorban the check for isMaximizeConnections() is now redundant.

Before this PR, when !create && isMaximizeConnections(), the code was calling tryCreate(maxPending).

With this PR, the call to tryCreate(maxPending) is done when create==false, so there would be no need to test for isMaximizeConnections(). However, I think it's no harm as round robin is more aggressive anyway.

If the test for isMaximizeConnections() is removed from these changes, then it's not used anywhere else and may probably be removed also from RoundRobinConnectionPool.

[lorban]

Indeed, isMaximizeConnections() is not strictly necessary anymore since the else branch may now try to create a connection anyway.

But without it, RR would only create new connections if it cannot find an idle one, which may or may not not be the expected behavior.

Personally, I think the default behavior should have been to spread the load across the smallest possible number of connections but since history has decided otherwise, this parameter should stay the way it is to default to spreading the load across the largest possible number of connections.

[lorban]

LGTM

[gregw]

I'm just giving this a -1 for now, as I think there is a way to do this atomically.
I will give it a try... and when it inevitably fails then I'll re-review

[sbordet]

@gregw work on #5858 showed that's still not possible to precisely create an exact number of connections, so the tradeoff remains that it's better to create a few more than let requests in the queue.