Handle non-zero subprocess exits (#5660)

With PR #5634 (which had the goal to remove I/O in event loop for backup
operations) the semantics of `remove_folder` changed slightly: Non-zero
exits of subprocesses were no longer handled, but lead to a
CalledProcessError.

Now to restore the semantics of `remove_folder` we should simply log an
error. However, this semantic change actually uncovered a potential
problem in deployed systems: There are 34 users on beta channel which
regularly seem to run `FixupStoreExecuteReset`, and with the semantic
change we see those errors in Sentry.

An obvious problem could be no storage. But in a quick test that would
not execute the repair in first place since the fixup has the job
condition `FREE_SPACE` set. So the problem is likely elsewhere.

With this change, we log the stderr of find, while still raising the
exception. With that we should get more context in Sentry to see what
could be the underlying error.

supervisor/utils/__init__.py

@@ -95,7 +95,7 @@ def remove_folder(
     if content_only:
         find_args.extend(["-mindepth", "1"])
     try:
-        proc = subprocess.run(
+        subprocess.run(
             ["/usr/bin/find", str(folder), "-xdev", *find_args, "-delete"],
             stdout=subprocess.DEVNULL,
             stderr=subprocess.PIPE,
@@ -103,10 +103,11 @@ def remove_folder(
             text=True,
             check=True,
         )
-        if proc.returncode != 0:
-            _LOGGER.error("Can't remove folder %s: %s", folder, proc.stderr.strip())
     except OSError as err:
         _LOGGER.exception("Can't remove folder %s: %s", folder, err)
+    except subprocess.CalledProcessError as procerr:
+        _LOGGER.error("Can't remove folder %s: %s", folder, procerr.stderr.strip())
+        raise procerr
 
 
 def remove_folder_with_excludes(