fix: requestTimeout monitors from sent

[ronag]

This changes so that requestTimeout measures how long a requests
has been in the pipeline (i.e. running). This is a more useful measure than how
long the request has been enqueued on the client, which is something
that is predictable.

Also normalizes the behavior between Pool and Client.

Fixes: #341

If user properly uses Client.busy there should be no difference in observed behavior.

[ronag]

Some failing tests to sort out if this is an acceptable approach.

[ronag]

Counting from the client queue makes little sense as a higher level abstraction (like Pool) might also have a queue.

[ronag]

@mcollina this was not reviewable, fixed now, sorry about that. If you approve I'll sort out the tests as well.

[mcollina]

Can you add a test?

[ronag]

Can you add a test?

I'll take that preliminary approval. Fixing tests.

[mcollina]

The change is ok

[ronag]

@mcollina: I found another issue while working at this. Basically i had to change maxAbortedPayload to a abortedTimeout which kind of makes more sense.

PTAL

[ronag]

Another option is to just always destroy the socket if a running request at the head of the pipeline is aborted. KISS? I.e. skip abortedtimeout and maxabortedpayload

[mcollina]

Kiss!

[ronag]

@mcollina KISS applied. PTAL

[mcollina]

lgtm

[ronag]

@delvedor FYI might also be of interest for you