Connection timeout is wrongly implemented

[redox]

Reading both the code of our createBrowserXhrRequester and createNodeHttpRequester I think the way we implemented the "Connection timeout" is really wrong.

This timeout should trigger when it took more than 2s to (TCP/HTTPS) connect but reading this code I understand that we really trigger this timeout whenever we haven't been receiving data within the next 2s (as the clearTimeout is done within the response callback). This is wrong, it should be the "responseTimeout" for this.

[Haroenv]

Looks like this was also wrong in v3? It's called reqTimeout, but it gets started as the connect timeout, which gets cleared on readystatechange:

https://github.com/algolia/algoliasearch-client-javascript/blob/11409ef891dac8f2d976682bb87e81c82d101a52/src/browser/createAlgoliasearch.js#L78

https://github.com/algolia/algoliasearch-client-javascript/blob/11409ef891dac8f2d976682bb87e81c82d101a52/src/browser/createAlgoliasearch.js#L187-L199

[Haroenv]

in node v3 it seems to be the same story:

https://github.com/algolia/algoliasearch-client-javascript/blob/11409ef891dac8f2d976682bb87e81c82d101a52/src/server/builds/node.js#L142

https://github.com/algolia/algoliasearch-client-javascript/blob/11409ef891dac8f2d976682bb87e81c82d101a52/src/server/builds/node.js#L161-L163

[Haroenv]

current status (as well as v3) is thus:

node:

• https.request is created
• connect timeout started
• request is .end ed (actually means it's started)
• "response" event (means first byte)
• connect timeout cancelled
• response timeout started
• "end" event
• response timeout cleared

browser:

• XMLHttpRequest is created
• connect timeout started
• request is .open ed (actually means it's started)
• "readystatechange" event is fired with > OPENED (means headers are arrived)
• connect timeout cancelled
• response timeout started
• "load" event
• response timeout cleared

What we want to find for both node & xhr is an event that gets called when TLS is finished, not when the headers / first byte is received, so that the connect timeout is long enough