HttpTransport with async pipelining

[John Arbash Meinel]

Well, I showed up on my split-transport branch again, and I decided to
try and implement some pipelining for http transport.
Basically, what I did was to change the effbot.org library, such that
http_client.async_http() instead of being a single object per file, it
now was a single object per schema+host+port. And then the objects would
build up a queue of requests. Otherwise you can't pipeline your requests
with the same connection. The old effbot.org method of using
http_manager actually created a new connection for each file, rather
than re-using the same one.

Anyway, with the modified versions, on my local network, instead of "bzr
branch" taking:
real    6m55.448s
user    1m12.872s
sys     0m34.342s

it now takes:
real    3m13.656s
user    0m50.325s
sys     0m23.665s

So I cut the time down to almost half. (relative to the current bzr.dev
tree).

Now, in theory, it should be going much faster, since I am nowhere near
bandwidth limited. And I made sure that GzipConsumer wasn't being used,
so that I wouldn't have to worry about being processor limited.

Now, there is still a lot of room for improvement, considering using my
RsyncTransport gets the time down to:
real    1m8.935s
user    0m18.351s
sys     0m10.911s

And that does seem to be bandwidth limited.

Perhaps a better implementation would take advantage of more information
at the http_manager level. For now, I don't use it at all, since I keep
my own map of connections.

Certainly, this could be done in a different way, since I created a
Request object to take the place of async_http. Probably the easiest
thing would be to update http_manager with a set of connections, which
it could then try to re-use when creating new async_http() objects.

But I wanted to put my changes out there, and let people look at them.
My current revno is 962.

Also, I'm still hoping to get my changes merged into the mainline. If
only for the SftpTransport and RsyncTransport support.

John
=:->