distinguish between read timeout and connect timeout

[hyj1991]

No description provided.

[coveralls]

Coverage increased (+1.5%) to 82.707% when pulling 003953c on hyj1991:master into 25963d1 on JacksonTian:master.

[JacksonTian]

空格。

[hyj1991]

done

[hyj1991]

lint 规则竟然没提示。

[hyj1991]

修改后，将 read timer 设置为 response/request 的底层依赖的 socket 的属性达到跨调用请求生命周期内的共享（官方暴露的 API，应该比较稳定： request.socket, response.socket）

[JacksonTian]

这个 code 应该叫 ReadTimeout 了吧。

[JacksonTian]

我感觉对 timer 的清理不够完整。

[JacksonTian]

return Promise.reject(new Error(RequestTimeoutReadTimeout: ${response.socket[READ_TIME_OUT]}));

更合适。

[JacksonTian]

现在的实现里，在 request 阶段 [connect, onresponse] 能顺利触发 request 的异常抛出。

但开始 read 到 end 之间，出现超时了，不能抛出异常。

[hyj1991]

@JacksonTian 这个库如果要真正设计 read timeout 其实有一个问题：

如果用户调用玩 request 方法后一直不去调用 read 方法，那么 request 方法里面 connect 结束后设置的 read timer 就无法去触发，因为 request 本身返回的是 promise.resolve(response)，而且当 request 方法正确返回时，这个 promise 的状态已经是 resolved 了，这时如果 read timer 超时，那里面的 reject 首先没有用，如果改为 throw 强制触发也违背了 promise 状态不能更改的设计原则

[hyj1991]

修改了下逻辑，补了下 read 动作的超时测试，目前只有一种逻辑下无法捕获 read 超时：

async function test() {
  const res = await httpx.request('/', { readTimeout: 300 });
  // 拿到 res 后永远不去读取，此时因为 httpx.request 返回的这个 promise 状态已经是 resolved 了，不会再发生更改 ，导致超时错误没有办法被捕获
  // 相反，如果故意等到 300ms 后再去执行 httpx.read 或者在执行 httpx.read 时发生 read timer 超时，是可以正确抛出的
}

[JacksonTian]

修改了下逻辑，补了下 read 动作的超时测试，目前只有一种逻辑下无法捕获 read 超时：

async function test() {
  const res = await httpx.request('/', { readTimeout: 300 });
  // 拿到 res 后永远不去读取，此时因为 httpx.request 返回的这个 promise 状态已经是 resolved 了，不会再发生更改 ，导致超时错误没有办法被捕获
  // 相反，如果故意等到 300ms 后再去执行 httpx.read 或者在执行 httpx.read 时发生 read timer 超时，是可以正确抛出的
}

这个是预期的。