conncache: only allow multiplexing within same multi handle

Connections that are used for HTTP/1.1 Pipelining or HTTP/2 multiplexing
only get additional transfers added to them if the existing connection
is held by the same multi or easy handle. libcurl does not support doing
HTTP/2 streams in different threads using a shared connection.

Closes #2152

docs/libcurl/curl_share_setopt.3

@@ -75,8 +75,15 @@ Put the connection cache in the share object and make all easy handles using
 this share object share the connection cache. Using this, you can for example
 do multi-threaded libcurl use with one handle in each thread, and yet have a
 shared pool of unused connections and this way get way better connection
-re-use than if you use one separate pool in each thread. Support for this was
-added in 7.57.0, but the symbol existed long before this.
+re-use than if you use one separate pool in each thread.
+
+Connections that are used for HTTP/1.1 Pipelining or HTTP/2 multiplexing only
+get additional transfers added to them if the existing connection is held by
+the same multi or easy handle. libcurl does not support doing HTTP/2 streams
+in different threads using a shared connection.
+
+Support for \fBCURL_LOCK_DATA_CONNECT\fP was added in 7.57.0, but the symbol
+existed before this.
 .RE
 .IP CURLSHOPT_UNSHARE
 This option does the opposite of \fICURLSHOPT_SHARE\fP. It specifies that

lib/url.c

@@ -1264,6 +1264,11 @@ ConnectionExists(struct Curl_easy *data,
            already in use so we skip it */
         continue;
 
+      if((check->inuse) && (check->data->multi != needle->data->multi))
+        /* this could be subject for pipeline/multiplex use, but only
+           if they belong to the same multi handle */
+        continue;
+
       if(needle->localdev || needle->localport) {
         /* If we are bound to a specific local end (IP+port), we must not
            re-use a random other one, although if we didn't ask for a