`verify=True` is not always honoured

The request `my_session.head(some_url, verify=True)` reuses existing connections, including any that were established with `verify=False`.

## Expected Result

I would expect that HTTP requests with `verify=True` would only reuse existing connections that were also established with `verify=True`.

## Actual Result

From my test-case, it seems that the session will reuse an existing connection, irrespective of how that connection was established.

## Reproduction Steps

The following code should demonstrate the problem.

```python
import requests
from urllib3.exceptions import (MaxRetryError, SSLError)

def do_head_request_on(strategy, verify):
    try:
        r = strategy.head("https://wrong.host.badssl.com/",
                          verify=verify)
        print("With verify %s,\tHTTP request made OK." % verify)
    except requests.exceptions.ConnectionError as ce:
        cause = ce.__context__
        if type(cause) is MaxRetryError:
            cause = cause.reason
        if type(cause) is SSLError:    
            print("With verify %s,\tTLS problem" % verify)
        else:
            raise ce

requests.packages.urllib3.disable_warnings()

print("NOT using sessions:")
do_head_request_on(requests, True)
do_head_request_on(requests, False)
do_head_request_on(requests, True)

session = requests.Session()

print("\nUSING sessions:")
do_head_request_on(session, True)
do_head_request_on(session, False)
do_head_request_on(session, True)
```

Here is the output on my machine:
```
NOT using sessions:
With verify True,       TLS problem
With verify False,      HTTP request made OK.
With verify True,       TLS problem

USING sessions:
With verify True,       TLS problem
With verify False,      HTTP request made OK.
With verify True,       HTTP request made OK.
```

The issue is that the final request has `verify=True` against a known-bad endpoint; however, the request is successful.

## System Information

    $ python -m requests.help

```json
{
  "chardet": {
    "version": "4.0.0"
  },
  "cryptography": {
    "version": "37.0.4"
  },
  "idna": {
    "version": "2.10"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.9.2"
  },
  "platform": {
    "release": "5.10.0-18-amd64",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "30000050",
    "version": "22.0.0"
  },
  "requests": {
    "version": "2.25.1"
  },
  "system_ssl": {
    "version": "101010ef"
  },
  "urllib3": {
    "version": "1.26.5"
  },
  "using_pyopenssl": true
}
```


Seemingly `Response.close` doesn't close the underlying connection from the Session: it remains available for a subsequent request.  Therefore, this doesn't provide a work-around for this issue.

There are (at least) a couple of work-around for this issue that do work.

1. Don't use a Session when making non-verified requests.
2. Use two Session objects: one Session object for "proper" TLS-verifying requests and a separate Session object for any requests with verifying disabled.

The above test-case demonstrates the first work-around.  The following code demonstrates the second work-around:

```python
import requests
from urllib3.exceptions import (MaxRetryError, SSLError)

def do_head_request_on(strategy, verify):
    try:
        r = strategy.head("https://wrong.host.badssl.com/",
                          verify=verify)
        print("With verify %s,\tHTTP request made OK." % verify)
    except requests.exceptions.ConnectionError as ce:
        cause = ce.__context__
        if type(cause) is MaxRetryError:
            cause = cause.reason
        if type(cause) is SSLError:    
            print("With verify %s,\tTLS problem" % verify)
        else:
            raise ce

requests.packages.urllib3.disable_warnings()

print("NOT using sessions:")
do_head_request_on(requests, True)
do_head_request_on(requests, False)
do_head_request_on(requests, True)

session = requests.Session()
insecure_session = requests.Session()
insecure_session.verify = False

print("\nUSING sessions:")
do_head_request_on(session, None)
do_head_request_on(insecure_session, None)
do_head_request_on(session, None)
```

Using this code, I see the desired output:
```
NOT using sessions:
With verify True,       TLS problem
With verify False,      HTTP request made OK.
With verify True,       TLS problem

USING sessions:
With verify None,       TLS problem
With verify None,       HTTP request made OK.
With verify None,       TLS problem
```


In the future, please search **closed and** open issues before creating new ones that are duplicates. https://github.com/psf/requests/issues/4391

Hi @sigmavirus24,

Sorry for the dup.  I didn't search for closed bugs because (from my perspective) this bug is still active.

If I've understood #4391 correctly, a fix for this issue has been committed, just not to the v2 branch.  Therefore, this problem with be fixed once people upgrade to the forthcoming (and currently unreleased) Requests v3.0.0.

That said, I humbly suggest that #4391 was prematurely closed.

This is because there is no release of Requests to which I can upgrade where the problem is fixed.  It's not clear where v3.0.0 will be released, so I don't know when I will be able to upgrade Requests to benefit from this fix.

Meanwhile, the problem still exists in v2.

Unfortunately, #4391 is now locked: it cannot be reopened nor does it accept any comments.  This issue (#6269) is also marked as "closed".  I feel this, too, was premature, but at least I can add a comment here, saying this.

If this problem cannot be fixed with Requests v2 (I see a pull request was rejected) then I think this issue should be documented as a known limitation (ideally with some work-around suggestions).  Ideally, the code would be updated to issue a warning if there's a likelihood of triggering this behaviour (provided the effort required is not too great).

So, please feel free to consider this issue as a problem with the documentation, if you feel v2 is unfixable.

HTH,
Paul.