New t.w.client API & Backend

[tdavis]

After a lot of testing and experimenting, I came to the conclusion that the current implementation of t.w.client (HTTPClient/HTTPClientFactory/getPage...) simply wasn't written to support persistent connections and couldn't come close to pipelining. I realized that even trying to make something that both worked with the current classes and worked with the new API would be way too difficult and kludgy to bother. So, I embarked on a mission into t.w2.client and found some code that is already up to the task.

Not a lot of changes were made to the t.w2.client code, except to remove the use of Streams and a couple other tiny things. The biggest thing t.w2.client was lacking was a usable API (at least that I could find) so it was never really a viable option. So, that makes up the bulk of the new backend whereas the API is completely new and only designed to work with the new backend. Current code will be marked as deprecated.

I will be posting code and tests for each piece of the new API as they are written. From there I will implement any recommended changes and reasonable features. The new backend will be posted last.

[glyph]

I hate to be a wet blanket, but this does not read as a ticket. It's more of a "note to self" than anything else.

I intend to close any tickets as invalid where it's not clear what the next actionable step is, so that it can be taken over by someone other than the original developer. There is no actionable step here for anyone but you: the task here is "post some code that I'm going to write". A ticket should be about why you are writing the code: what is the requirement? What will this code do? "Be new" is not a valid answer. It has to do something that someone actually wants it to do.

It sounds like the thing that this new code will do that is better is support pipelining. We already have a ticket explaining that feature. Please feel free to post your new backend as patches on that ticket, rather than using this one. If you can't figure out how to fix that without fixing a bunch of other, related issues in the process - great! Link to those tickets as well, and explain why the fix is all fused together. Perhaps it can be split into smaller chunks for faster review, but if not, it would be much better to review a patch that says "fixes these 12 issues" than "totally new and improved!"