Only assign NULL to data->easy_conn directly.

This commits replaces occurances of *connp = NULL with
data->easy_conn = NULL, adding DEBUGASSERT to make sure
that this is allowed.

What this comes down to is that we only want to set easy_conn
to NULL when the connection is owned by the SessionHandle
that contains that easy_conn. Thus:

data->easy_conn = NULL;

is only allowed while data->easy_conn->data == data.

This prepares a future commit that will need fact.

Note that this commit also removes a duplicate variable
in curl_multi_remove_handle (nl. 'easy') because it was
an alias for 'data' and having two different variables for
the exact same thing did not make the code better understandable.
In particular, now we can read 'data->easy_conn->data == data'
and 'data->easy_conn->data = data' which is exactly what we
want/need ;).

Finally, in Curl_reconnect_request() we pass connp to
Curl_done() instead of &conn (where conn is a local variable).
The reason is that 'connp' fullfills the above assertion that
Curl_done needs while '&conn' doesn't. There is not functional
difference since 'conn' is not used below this call, *connp
is assigned NULL below that call, and initially conn == *connp.
pipelining: keep used sockets in pipeline active.

This fixes bug https://sourceforge.net/p/curl/bugs/1445/

Libcurl historically has a strict one-on-one relationship between (easy)
handles (struct SessionHandle, often called 'data') and connections
(struct connectdata, often called 'conn'). This is apparent from the fact
that data->easy_conn points to the connectdata that 'data' is using
while conn->data points back to its 'owner'.

Since pipelining this picture has changed: many easy handles can be
using a single connection. While this doesn't seem to pose a problem the
single 'easy_conn' pointer, the single 'conn->data' pointer becomes
questionable. The latter has been partially addressed by stating that
only easy handles at the head of a pipe would be 'owners', but that
still would leave two owner: one request that is at the head of the send
pipe and potentially one that is at the head of the recv pipe. Moreover,
this picture simply doesn't hold: a LOT of code depends on some kind of
relationship without which functionality breaks EVEN when the request
being handled is NOT at a pipe head. This is mostly the case for handles
that timed out (which however is also abused to process newly added
handles which might not be at the head) and for example when handles are
being closed (ie, as a result of a pipe break), etc.

After a deep investigation I determined that the following relationship
is sufficient and required: data->easy_conn->data == data. When at the
right places this relationship is ensured then the code works as
intended. For all other means one has to assume that data->easy_conn can
point to any request-- at 'random'-- and is not useful for pipelining to
be used. Instead one should look at conn->send_pipe and conn->recv_pipe,
which hold all information needed ON TOP of the request being handled
(conn->data, which does not necessarily have to be in either pipe at
all).

This commit centers around a functional bug in how singlesocket()
worked: this function is responsible for adding and removing 'active'
sockets from being watched for activity. It had two problems:
1) when data->easy_conn is set to NULL before calling this function, it
has no direct access to the connectiondata, or send_pipe/recv_pipe
thereof, and hence was not able to take the correct information into
account. The result was that socket were removed from being watched for
activity while other request(s) still existed that needed this.
2) The top part of the function intended to only add new sockets: start
watching them for either POLL_IN or POLL_OUT, but inadvertedly could
switch an action from POLL_OUT to POLL_IN while *another* request in the
send_pipe still needed the POLL_OUT.

The way singlesocket() works is by asking for the current action on the
active sockets on the handle being passed and compare that to the action
that this socket needed last time. From that it is deduced which changes
are needed for that socket. If a removal is needed (of either POLL_IN,
POLL_OUT or both) then it double checks with the send_pipe and recv_pipe
to see if that's ok: if not other requests still need that action, and
if not makes the change.

The solution used to fix problem 1) is that when a socket is
disassociated from a connection (setting easy_conn to NULL) then
immediately it is checked if other requests in the pipes require a
socket to be handled; and if that is the case to also disassociate the
handle from the socket (clearing data->socket[]). This algorithm is
implemented in the new functions Curl_disassociate_socket() and
Curl_disassociate_conn(). The latter is to be called when formerly
easy_conn was set to NULL, except when the connection was freed and/or
could be freed while the connection became unusable for all request.

Note that because of all this, a strict policy needed to be followed:
whenever a connectdata is freed, we do not want an easy_conn to still
point to it; otherwise it might still be accessed (ie, by calling
Curl_disassociate_conn()). Therefore I built in into Curl_disconnect()
that easy_conn is set to NULL when freed. That also means that it is no
longer needed to do that elsewhere (ie, immediately after returning from
Curl_disconnect or as function of some return value), ie, after calling
Curl_async_resolved(). easy_conn is now set to NULL automatically
whenever the connection is freed.

This commit fixes another bug by disassociating all handles from
disconnected sockets (in Curl_disconnect()). Before it was possible that
this same socket fd was reused by another request before old request,
still having that fd in their socket[] area, would -say- time out and
get processed - which could lead to that socket being seens as going
from active to non-active and being removed from select() while still
being used by another connnectdata struct and handles.