conn vs data cleanup

[bagder]

Easy handles and connections

History

A common pattern in the libcurl code is having connections (struct
connectdata) point to its corresponding transfer (easy handle) using the
conn->data struct member.

We therefore pass around the 'conn' pointer only in a lot of places as we can
defer the transfer from it (using conn->data).

This made perfect sense back in the days when each transfer had a single
connection for the duration of a transfer and became less good when we added
Pipelining and downright ugly when we added support for multiplexed
connections.

Now, several simultaneous transfers can use the same connection so conn->data
has to be updated very frequently to make it accurate for every possible
situation. This is error-prone and is repeteadly a reason for issues and bugs.

Two transfers using two connections

    /------------\          /--------------\
    | Transfer 1 |   ===>   | Connection 1 |
    | 'data'     |          \--------------/
    \------------/

    /------------\
    | Transfer 2 |          /--------------\
    | 'data'     |   ===>   | Connection 2 |
    \------------/          \--------------/

Two transfers using one connection

    /------------\          /--------------\
    | Transfer 1 |   ===>   | Connection 1 |
    | 'data'     |     -->  \--------------/
    \------------/    /
                     /
    /------------\  /
    | Transfer 2 | /
    | 'data'     |
    \------------/

A better way

A transfer however only uses a single connection for a transfer (or none at
all) at any given time. data->conn gets assigned when a connection is setup
and it gets cleared when the connection is again closed or returned to the
connection pool. Several transfers can point to the same connection while they
multiplex over the same one.

Going forward

Use of 'conn->data' should be removed over time in preference to 'data->conn'.
Function prototypes should rather work with struct Curl_easy *data as the
identifier poiting out the specific transfer and 'data->conn' to get the
connection (which then is NULL if there is no associated connection for this
transfer), rather than the old style that passes in struct connectdata *conn
to most functions.

• Curl_attach_connnection() - this is the new function that gets called when
  a connection is "attached" to a transfer. When the two gets their
  association. The association is then kept until detached at a later point.

• Curl_detach_connnection() - this is the new function that gets called to
  separate the tranfer from its associated connection. From this point on,
  the transfer has no longer any associated connection.

Gradual, not single-shot

I previously made an attempt in making this change (basically removing
conn->data) in a single shot, a single pull-request, but even before it was
completed the changeset reached over 3000 modified lines. Quite simply too
large to be reviewable and landable in one atomic change.

That experience made me draw the conclusion that we need to make this change
gradually and over time.

Over time, data->conn should be used and conn->data use should be reduced.

[jay]

I think it will probably be a bit rocky regardless. As it is it looks fine to me however CI re Curl_connect create_conn does not always allocate for conn.

[bagder]

I think it will probably be a bit rocky regardless.

Probably, yes. But I still think doing it gradually instead of a huge single merge will make a softer landing.

As it is it looks fine to me however CI re Curl_connect create_conn does not always allocate for conn.

Clearly some more fixes are needed to make the builds green...

[bagder]

Fixed the merge conflicts #3448 caused.