fix(resize): recover from part-way failed resizes

[apricote]

If a previous resize attempt failed after calling POST /v1/volumes/{id}/resize (rate limit, network connectivity, ...), the volume might already have the target size.

The PVC (in Kubernetes) would still have the old size in its status, so the external-resizer makes another attempt at the resize. In the Hetzner Cloud API, a resize must always be larger than the current size, so the new resize failed with:

volume size is too small (invalid_input)

This is now fixed, as we compare the size of the Hetzner Cloud volume to the desired size and only proceed if an actual resize is needed.

This was a violation of the CSI Spec[0], which stated for ControllerExpandVolume:

This operation MUST be idempotent. If a volume corresponding to the specified volume ID is already larger than or equal to the target capacity of the expansion request, the plugin SHOULD reply 0 OK.

[0] https://github.com/container-storage-interface/spec/blob/release-1.9/spec.md#controllerexpandvolume

[codecov]

Codecov Report

Attention: Patch coverage is 55.00000% with 9 lines in your changes missing coverage. Please review.

Project coverage is 45.16%. Comparing base (487fd6a) to head (0739b2f).

Files	Patch %	Lines
api/volume.go	61.53%	4 Missing and 1 partial ⚠️
volumes/idempotency.go	42.85%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #623      +/-   ##
==========================================
+ Coverage   43.01%   45.16%   +2.15%     
==========================================
  Files          12       12              
  Lines        1174     1169       -5     
==========================================
+ Hits          505      528      +23     
+ Misses        650      618      -32     
- Partials       19       23       +4     

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

[apricote]

Approved from my side too, as soon as the e2e tests are green.