fix: recover stale luks device mapper

[lukasmetzner]

No description provided.

[codecov]

Codecov Report

❌ Patch coverage is 51.92308% with 25 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.64%. Comparing base (22f4b1a) to head (09312be).

Files with missing lines	Patch %	Lines
internal/volumes/cryptsetup.go	52.00%	24 Missing ⚠️
internal/volumes/resize.go	50.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1364      +/-   ##
==========================================
- Coverage   71.97%   71.64%   -0.33%     
==========================================
  Files          17       17              
  Lines        1520     1552      +32     
==========================================
+ Hits         1094     1112      +18     
- Misses        338      352      +14     
  Partials       88       88              

Flag	Coverage Δ
e2e-controller	55.60% <19.23%> (-1.11%)	⬇️
e2e-node	55.60% <19.23%> (-1.11%)	⬇️
integration	3.10% <0.00%> (-0.09%)	⬇️
unit	41.10% <32.69%> (+0.25%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ 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.

[lukasmetzner]

Debugging information provided by customer indicates there is an issue with luks device mappers not being closed properly. I could not yet reproduce this correctly, but this would address the issue.

[lukasmetzner]

As an addition, I properly introduced context management into the cryptsetup. Required a little refactor, but this is mostly just dragging along the context.

[Jank1310]

@lukasmetzner I think we got hit by somthing related to this pr
Happy to share the full hcloud-csi-node logs and cryptsetup status if needed

AI

A dm-crypt mapper left over from an earlier attach cycle stayed active while pointing at a dead dev_t — cryptsetup status reported type: n/a / device: (null). Since Open() short-circuits on IsActive(), which only inspects cryptsetup's exit code and discards its output, the driver reused that zombie mapper; mount-utils then concluded it was unformatted and ran mkfs.ext4 -F against it — 708 times over 23.8 hours, each attempt failing with I/O errors and emitting a fresh Filesystem UUID.

I ran this PR's NewLUKSDeviceStatus/IsZombie() against our verbatim cryptsetup status output and it returns true, so #1364 would have closed the stale mapper and re-opened LUKS against the real device instead of mkfs-ing a dead one.