locking with python3-etcd3 0.12.0 on etcd 3.4.23 fails?

I'm using a test cluster of three etcd nodes running etcd version 3.4.23.

When using python `etcd3==0.12.0` my attempts to test etcd3 locks (see [test_lock.txt](https://github.com/kragniz/python-etcd3/files/11173245/test_lock.txt)) across multiple processes blows up, with different errors depending on which version of tenacity I'm using. With the following:

```
etcd3==0.12.0
grpcio==1.53.0
protobuf==3.20.3
six==1.16.0
tenacity==8.2.2
```

I get the error:

```
Traceback (most recent call last):
File "/app/./test_lock.py", line 24, in
p.map(test_lock, [i+nid for i in range(nproc)])
File "/usr/local/lib/python3.10/multiprocessing/pool.py", line 364, in map
return self._map_async(func, iterable, mapstar, chunksize).get()
File "/usr/local/lib/python3.10/multiprocessing/pool.py", line 771, in get
raise self._value
TypeError: Lock.acquire..wait() missing 1 required positional argument: 'delay_since_first_attempt'
```

and with a lower version of tenacity:

```
etcd3==0.12.0
grpcio==1.53.0
protobuf==3.20.3
six==1.16.0
tenacity==8.1.0
```

I get the error

```
Traceback (most recent call last):
File "/app/./test_lock.py", line 24, in
p.map(test_lock, [i+nid for i in range(nproc)])
File "/usr/local/lib/python3.10/multiprocessing/pool.py", line 364, in map
return self._map_async(func, iterable, mapstar, chunksize).get()
File "/usr/local/lib/python3.10/multiprocessing/pool.py", line 771, in get
raise self._value
TypeError: Lock.acquire..wait() got an unexpected keyword argument 'retry_state'
```

Installing python-etcd3 from the master branch (using `pip install git+https://github.com/kragniz/python-etcd3`) appears to resolve the issue, so:

```
etcd3 @ git+https://github.com/kragniz/python-etcd3@e58a899579ba416449c4e225b61f039457c8072a
grpcio==1.53.0
protobuf==3.20.3
six==1.16.0
```
appears to work fine:

```
python3 ./test_lock.py
does 1 have the lock? True
does 2 have the lock? True
does 3 have the lock? True
does 4 have the lock? True
```

Start with the attached test_lock.txt and the test_lock.py invocation described in the report, using the listed etcd3, grpcio, protobuf, and tenacity versions. Compare the lock behavior at commit e58a899 with the 0.12.0 release and verify the multiprocessing scenario across the reported tenacity versions. Done means the lock test runs without the reported TypeError and the fix is available in a released version.

Written by the indexing model from the issue text.