Potential cache/throttle race conditions in Connector._resolve_host with traces

[ojii]

Long story short

If traces are used in TCPConnector._resolve_host the context switch introduced by awaiting their trace API calls can lead to various race conditions.

For example the DNS cache hit test may evaluate True but by the time traces is done it may already be gone again.

The same is true for the throttling logic where between checking that the key is already throttled and then accessing that key the key may already be popped.

Similarly in the opposite case of the above, with traces enabled, the code might override an already set throttled event

Steps to reproduce

See my branch

In the tests I mess with the caches from the traces directly to simulate the effects for simplicity.