fix: use asyncio.Lock over Event

[jackwotherspoon]

We are currently improperly using asyncio.Event in our code. Event is meant to be used with the wait coroutine to hold coroutine from running until the set() is called. We don't use wait anywhere in our code thus this is not having the intended effect.

Much easier to just use asyncio.Lock which allows usage as a context manager to acquire/release the mutex lock.

[enocom]

We might need to carefully audit all the reads and writes to self._current and self._next. I'd expect to see us holding the lock whenever we read or write from those values. WDYT?

[hessjcg]

The Go and Java connectors use the mutex to protect access and modification of self._next and self._current to avoid race conditions that occur when there are concurrent requests to refresh from multiple threads. The python connector probably needs to do the same. See Go RefreshAheadCache instantiation and scheduleRefresh()

[jackwotherspoon]

Still have a couple more spots to acquire the lock, the tricky one is in the RefreshAheadCache constructor as Python __init__ functions are sync by default. Might have to add an async class method and use it to initialize the cache so that I can properly use the lock.

cloud-sql-python-connector/google/cloud/sql/connector/instance.py

Lines 97 to 99 in f8de0f1

	self._lock = asyncio.Lock()
	self._current: asyncio.Task = self._schedule_refresh(0)
	self._next: asyncio.Task = self._current