HttpClient's SelectConnector clean-up

1. SelectChannel contains the _blockingConnect field together with a setter/getter pair. These seem not be used at all. SelectChannel isn't currently prepared to handle both blocking and non-blocking connect modes. In the current impl connect is always blocking, so this field is not used. If it was to be used, startConnection would need to be completely refactored, so that mode is checked, finishConnection() is used (or exposed to some other HttpClient's components as some entity needs to implement timeouts on connect), etc.

2. I'm not sure if the way connect timeout is now implemented is correct. I haven't played with low level OS stuff for some time. However, I think that just setting soTimeout before calling connect() is not enough. Please correct me if I'm wrong .

SelectConnector source code reads:

>>> channel.socket().setSoTimeout(_httpClient.getConnectTimeout());
channel.connect(address.toSocketAddress());
channel.configureBlocking(false);
>>> channel.socket().setSoTimeout((int)_httpClient.getTimeout());

SoTimeout is set twice and I think that the first one is ignored. I haven't looked at Sun's impl of SocketChannel, so I don't know if there's a clean way to do it, but the brute force workaround that I can think of is to use:

channel.socket().connect(socketAddress, _httpClient.getConnectTimeout());

instead of:

channel.socket().setSoTimeout(_httpClient.getConnectTimeout());
channel.connect(address.toSocketAddress());

However, SocketChannel impl would need to be checked in order to understand if just calling channel.socket().connect(socketAddress, _httpClient.getConnectTimeout()); is ok.

------------------

I marked this JIRA as only affecting Jetty 7.2.2, but it's likely that all versions from the Jetty 7.x branch are affected.