Abort SSL connections on close, rather than waiting for remote EOF.

[tomchristie]

In order to close encode/httpx#825 and encode/httpx#914

Probably needs tests to check that:

• We have ResourceWarnings prior to this, but don't have any after it.
• Possibly an integration test making a request to a poor SSL shutdown URL, to show that it doesn't hang on close.

[florimondmanca]

Possibly an integration test making a request to a poor SSL shutdown URL, to show that it doesn't hang on close.

I looked at https://badssl.com to see if they had a public endpoint for this scenario, but it doesn't seem so (only mostly scenarios for certs-related issues).

[agronholm]

All AnyIO backends should do this properly when standard_compatible=False is passed to TLSStream.wrap() (as backends/anyio.py does).

[tomchristie]

@agronholm Grand - good to know. Any pointers on good ways to test our behaviour before/after this fix?

[agronholm]

If the client SSLSocket is receiving an unexpected EOF, it should raise ssl.SSLEOFError. Does the http server you test against unconditionally abort the connection on close?

[cdeler]

Looks like we really need to do that.

As an alternative we can introduce a "close" timeout as the "connect" timeout we already have which can be fired as a last resort

[florimondmanca]

Sounds good. Ideally we'd be adding some tests as Tom suggested in PR description, but I'm also happy enough to merge and release and see if anything breaks. :-)

[cdeler]

I think, I hit this problem (probably it was exactly this unclosed socket) while I tried to write the test for #235

[lazka]

I'm hitting some problems potentially caused by this change: encode/httpx#1459

Any ideas?