Drop/Replace lock file test in test_xdr

[jeremyleung521]

Fixes #5236

To be honest, the test (test_offset_lock_created) does not make sense to me since it was testing if we ever locked a file before and not actual current behavior of locking a file (and was apparently never tested in windows due to filelock's behavioral differences across OSes). Now that UNIX behavior is same as Windows (orphaned lock file automatically deleted after unlock), it seems ok to remove the test.

First commit removes the test. Second commit implements a replacement test where "open/acquire a lock --> check --> release it --> check it's gone."

I ran flake8 on the file and there were some unused imports which I removed.

(EDIT: The striked-out part apparently is no longer true from a commit five days ago... what a mess)

Changes made in this Pull Request:

• Removed the relevant test (test_offset_lock_created) that involves checking for a lock file after the file lock had been released

LLM / AI generated code disclosure

LLMs or other AI-powered tools (beyond simple IDE use cases) were used in this contribution: no

PR Checklist

• Issue raised/referenced?
• Tests updated/added?
• Documentation updated/added?
• package/CHANGELOG file updated?
• Is your name in package/AUTHORS? (If it is not, add it!)
• LLM/AI disclosure was updated.

Developers Certificate of Origin

I certify that I can submit this code contribution as described in the Developer Certificate of Origin, under the MDAnalysis LICENSE.

---

📚 Documentation preview 📚: https://mdanalysis--5237.org.readthedocs.build/en/5237/

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.82%. Comparing base (e6c1b44) to head (9f91684).
⚠️ Report is 4 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #5237      +/-   ##
===========================================
- Coverage    93.83%   93.82%   -0.01%     
===========================================
  Files          180      180              
  Lines        22475    22473       -2     
  Branches      3190     3189       -1     
===========================================
- Hits         21090    21086       -4     
- Misses         923      924       +1     
- Partials       462      463       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jeremyleung521]

Seems like it's an active place of contention/change... so maybe it's worth waiting... or just pin to 3.20.3... or remove the test.

tox-dev/filelock#494

[PardhavMaradani]

Adding a data point: The newly released filelock 3.24.3 which has a fix for the above mentioned issue does not resolve our test failure - verified this on a local setup. Thanks

[jeremyleung521]

Adding a data point: The newly released filelock 3.24.3 which has a fix for the above mentioned issue does not resolve our test failure - verified this on a local setup. Thanks

Seems like the fix filelock implemented for the issue I referenced earlier was a more robust loop for acquiring locks.

So the behavior now is: explicitly delete lock file after release for UNIX and leave lock file orphaned after release for windows. This is the exact opposite behavior from <= 3.20.3, which is why the (old) test still fails.