More explicit error message if transport is already closed

[lmazuel]

Fix #25640

We're not sure if we can auto-reopen the connection once it's closed, this can lead to leaky socket behavior. Therefore, this PR is just making explicit with a better error message that it's closed already.

Interesting thing is that if we call close while we never opened it, it shouldn't fail (it would be a bad breaking change), so the approach here is to track the open and the close event, for better acuracy.

I take the opportunity of this PR to fix the typing cast, that was ironically hidding bug #25640 (mypy tried to tell me, but I didn't listen at the time :p)

[johanste]

We should make sure we didn't break child clients/shared transports (e.g. storage container -> blob client)

[azure-sdk]

API change check

API changes are not detected in this pull request.

[xiangyan99]

Now in the case of
open -> close -> open again,
we change the error type from AttributeError to ValueError, should we keep raising AttributeError and just update the error message?

[lmazuel]

Now in the case of open -> close -> open again, we change the error type from AttributeError to ValueError, should we keep raising AttributeError and just update the error message?

To me, an AttributeError from a client like that is a bug, so we're not breaking working code, but fixing an unexpected error. I don't see a scenario where a customer will write code to expect an AttributeError and recover from it (but of course everything is a breaking change :)). So I still vote to keep ValueError, but of course I'm open to various opinions.

[xiangyan99]

LGTM.

Unless our architects have concerns on the error type change.

[lmazuel]

We should make sure we didn't break child clients/shared transports (e.g. storage container -> blob client)

We're passing the Storage tests, is that enough @johanste ?