Handle asynchronous cancellations for HTTPConnection instances

[karpetrosyan]

Motivated by https://github.com/encode/httpx/issues/947 🔥

Closes #785

This pull request just adds some logic to check if the connection was previously used or if it's just been created. Now the example from #785 works fine(?).

It's very hard to explain where the problem actually is, but I think you can find the answer to that question in #785.

In simple words, the client always thinks that there cannot be a connection that has not failed and is also not in the connecting process. This is because every connection is attached to some request when it's created, and there are no cases when it can just hang in our connection pool except for asynchronous cancellations.

Now the HTTPConnection instances can be new if "._is_new" is set to true and failed if "._connect_failed" is set to true. Otherwise, if both of them are false, that means it's in the connecting process.

[karpetrosyan]

Alternatively, we can add states for HTTPConnection instances (NEW, CONNECTING, FAILED), but I believe we should avoid that because we already have connecting states in HTTP11Connection instances.

[TheTechromancer]

This PR works well based on my testing.

[karpetrosyan]

Now the connection has a state of connecting, even if it was just created and is not trying to connect somewhere. This pull request simply adds the new state for such connections.

[T-256]

Now #785 closed, I think you can close this PR too.