refactor: remove handle_permission_denied function from rm linux platform

Remove the obsolete `handle_permission_denied` helper function in `src/uu/rm/src/platform/linux.rs`. This function was handling permission denied errors when attempting to remove subdirectories during recursive removal. Its removal simplifies the code and aligns with updated error handling logic, potentially avoiding redundant or buggy behavior in edge cases. The change maintains compatibility for standard rm operations while reducing complexity.

Author: mattsu2020

src/uu/rm/src/platform/linux.rs

@@ -187,37 +187,6 @@ fn handle_error_with_force(e: std::io::Error, path: &Path, options: &Options) ->
     !options.force
 }
 
-/// Helper to handle permission denied errors
-fn handle_permission_denied(
-    dir_fd: &DirFd,
-    entry_name: &OsStr,
-    entry_path: &Path,
-    options: &Options,
-) -> bool {
-    // When we can't open a subdirectory due to permission denied,
-    // try to remove it directly (it might be empty).
-    // This matches GNU rm behavior with -f flag.
-    if let Err(remove_err) = dir_fd.unlink_at(entry_name, true) {
-        // Failed to remove - show appropriate error
-        if remove_err.kind() == std::io::ErrorKind::PermissionDenied {
-            // Permission denied errors are always shown, even with force
-            show_permission_denied_error(entry_path);
-            return true;
-        } else if !options.force {
-            let remove_err = remove_err.map_err_context(
-                || translate!("rm-error-cannot-remove", "file" => entry_path.quote()),
-            );
-            show_error!("{remove_err}");
-            return true;
-        }
-        // With force mode, suppress non-permission errors
-        return !options.force;
-    }
-    // Successfully removed empty directory
-    verbose_removed_directory(entry_path, options);
-    false
-}
-
 /// Helper to handle unlink operation with error reporting
 fn handle_unlink(
     dir_fd: &DirFd,