Async clusters: Support creating locks inside async functions

[utkarshgupta137]

Pull Request check-list

• Does $ tox pass with this change (including linting)?
• Do the CI tests pass with this change (enable it first in your forked repo and wait for the github action build to finish)?
• Is the new or changed code fully tested?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?
• Is there an example added to the examples folder (if applicable)?
• Was the change added to CHANGES file?

Description of change

This allows creating the client at the module level or before the event loop has been initialized.
Ref: encode/starlette#1315 (comment)

[utkarshgupta137]

@chayim @dvora-h This is a minor fix which should be included in 4.4.0. If it is still far away, I can raise a PR for the 4.3 branch as well.

[codecov-commenter]

Codecov Report

Base: 92.22% // Head: 92.21% // Decreases project coverage by -0.00% ⚠️

Coverage data is based on head (f9363db) compared to base (c48dc83).
Patch coverage: 80.00% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2471      +/-   ##
==========================================
- Coverage   92.22%   92.21%   -0.01%     
==========================================
  Files         113      113              
  Lines       29321    29325       +4     
==========================================
+ Hits        27042    27043       +1     
- Misses       2279     2282       +3     

Impacted Files	Coverage Δ
redis/asyncio/cluster.py	91.68% <80.00%> (-0.11%)	⬇️
tests/test_cluster.py	96.89% <0.00%> (-0.12%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[chayim]

@utkarshgupta137 We're still waiting on #2407 and given your fix.. I'm pretty good with this getting into 4.4 as that merge. Let's give a bit longer (end of week maybe) for your PR in arq, and then we can merge it down + decide.

Does that work for you? I'd really like to not have multiple releases :D

[utkarshgupta137]

@utkarshgupta137 We're still waiting on #2407 and given your fix.. I'm pretty good with this getting into 4.4 as that merge. Let's give a bit longer (end of week maybe) for your PR in arq, and then we can merge it down + decide.

Does that work for you? I'd really like to not have multiple releases :D

Sure, it would work for me. But I don't think it is reasonable to wait for a third-party package to fix what is essentially a misuse (undefined behaviour) on their end. For all we know, there could be many other packages out there misusing some functionality of this package...
Also, there are other breaking changes in this release, so ideally, packages using redis as a dependency should have a version cap.

[chayim]

@utkarshgupta137 I randomly head out to the internet and contribute version caps for reasons like this. Part of a general goal of not breaking the community means I was happy to delay in this case, especially with the backport to 4.3.5.

Thanks again for the fix in arq - this goes into 4.4x.