feat: adds option not to raise exception when leaving context manager after lock expiration

[julianolm]

Fixes: #3532

Pull Request check-list

Please make sure to review and check all of these items:

• Do tests and lints pass with this change?
• 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?

NOTE: these things are not required to open a PR and can be done
afterwards / while the PR is open.

Description of change

I was having trouble using async locks with the context manager because it was failing when exiting the context manager after timeout had expired (even if my code executed successfully).

I would really like not to raise a LockNotOwnedError in the exit of the context manager (if I try to release a lock and it was already "released" then great!).

I understand just changing the behavior would be critical, so I added an option to just behave this way when desired instead.

Issue: #3532

[julianolm]

PTAL ?
@andymccurdy @dvora-h @chayim @petyaslavova @vladvildanov

[petyaslavova]

Hi @julianolm, thank you for your contribution! Your change will be reviewed soon.

[petyaslavova]

Hi @julianolm, can you please check the reported errors from code linters?

[julianolm]

Hey @petyaslavova , updated!!! Thanks!

[petyaslavova]

@julianolm you can run the linters locally - there are instructions in the contributing guide.
Instead of using the "invoke all-tests" command, you can just call "invoke linters" and you will see all reported errors and changes that are needed.

[julianolm]

Oh, great. Sorry I missed it.
Now its ok.
Thanks again @petyaslavova

[julianolm]

@petyaslavova wdyt?

[petyaslavova]

Hi @julianolm, you have conflicting change with the current master code and small change requested. Once these are resolved, we are ready to merge your change.

[petyaslavova]

The requested changes are in a previously posted comment.

[julianolm]

Hey @petyaslavova thanks! Gonna address those today asap!

[julianolm]

Hello, @petyaslavova . Sorry for the delay. Busy day at work today.

Requests addressed. I felt it was better to catch both LockNotOwnedError and LockError separetely just so we can log more precise warnings on each situation.

But I will leave an opened suggestion for a single catch (of parent class LockError) if you think it is better. Please feel free to commit or discard it.

Thanks again!

[julianolm]

PS: I ran the tests with above suggestions applied and it works just fine as well

[petyaslavova]

But I will leave an opened suggestion for a single catch (of parent class LockError) if you think it is better. Please feel free to commit or discard it.

I left one warning - in case you just want to print a warning instead of failing, I don't think having different detailed messages will be so important.

[petyaslavova]

But I will leave an opened suggestion for a single catch (of parent class LockError) if you think it is better. Please feel free to commit or discard it.

I left one warning - in case you just want to print a warning instead of failing, I don't think having different detailed messages will be so important.

@julianolm And now unfortunately, linters are failing ...

[julianolm]

Hello @petyaslavova linter problems solved