fix: Status codes for Space Disable/Delete

Allow a "permission denied error" from reva to bubble up to the client.
Reva was fixed to return "permission denied" only when the space to be
delete can actually be listed by the user. Other wise it will return
"not found". See reva commit 1bf72cb76394671f373e87f15f23f978cf41ab08.

So when a user with the 'can manage' role tries to purge an already
disabled space it will now get "Forbidden" status instead of a "Not
found".

Also fixes the expected status codes in the tests.

services/graph/pkg/service/v0/drives.go

@@ -1119,7 +1119,7 @@ func (g Graph) DeleteDrive(w http.ResponseWriter, r *http.Request) {
 		return
 	case cs3rpc.Code_CODE_PERMISSION_DENIED:
 		logger.Debug().Interface("id", rid).Msg("could not delete drive: permission denied")
-		errorcode.ItemNotFound.Render(w, r, http.StatusNotFound, "drive not found")
+		errorcode.AccessDenied.Render(w, r, http.StatusForbidden, "permission denied")
 		return
 	case cs3rpc.Code_CODE_NOT_FOUND:
 		logger.Debug().Interface("id", rid).Msg("could not delete drive: drive not found")

tests/acceptance/features/apiSpaces/disableAndDeleteSpaces.feature

@@ -63,28 +63,28 @@ Feature: Disabling and deleting space
   Scenario Outline: user cannot delete their own space without first disabling it
     Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
     When user "Alice" deletes a space "Project Moon"
-    Then the HTTP status code should be "400"
+    Then the HTTP status code should be "<code>"
     And the user "Alice" should have a space called "Project Moon"
     Examples:
-      | user-role   |
-      | Admin       |
-      | Space Admin |
-      | User        |
-      | User Light  |
+      | user-role   | code |
+      | Admin       | 400  |
+      | Space Admin | 400  |
+      | User        | 403  |
+      | User Light  | 403  |
 
 
-  Scenario Outline: user can delete their own disabled space via the Graph API
+  Scenario Outline: user cannot delete their own disabled space via the Graph API
     Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
     And user "Alice" has disabled a space "Project Moon"
     When user "Alice" deletes a space "Project Moon"
-    Then the HTTP status code should be "204"
-    And the user "Alice" should not have a space called "Project Moon"
+    Then the HTTP status code should be "<code>"
+    And the user "Alice" <shouldOrNot> have a space called "Project Moon"
     Examples:
-      | user-role   |
-      | Admin       |
-      | Space Admin |
-      | User        |
-      | User Light  |
+      | user-role   | code | shouldOrNot |
+      | Admin       | 204  | should not  |
+      | Space Admin | 204  | should not  |
+      | User        | 403  | should      |
+      | User Light  | 403  | should      |
 
 
   Scenario Outline: an admin and space manager can disable other space via the Graph API
@@ -134,7 +134,7 @@ Feature: Disabling and deleting space
 
   Scenario Outline: viewer and space editor cannot disable space
     When user "<user>" tries to disable a space "Project Moon" owned by user "Alice"
-    Then the HTTP status code should be "404"
+    Then the HTTP status code should be "403"
     And the user "<user>" should have a space called "Project Moon"
     Examples:
       | user  |

tests/acceptance/features/apiSpaces/spaceManagement.feature

@@ -152,11 +152,14 @@ Feature: Space management
 
   Scenario Outline: space admin user tries to disable the personal space
     When user "<user>" disables a space "Alice Hansen" owned by user "Alice"
-    Then the HTTP status code should be "404"
+    Then the HTTP status code should be "<code>"
     Examples:
-      | user  |
-      | Brian |
-      | Carol |
+      | user  | code |
+      # Brian is Space Admin and can currently list all Personal Spaces, so he
+      # gets a 403 instead of a 404 here. This might change in the future see:
+      # https://github.com/opencloud-eu/opencloud/issues/2979
+      | Brian | 403  |
+      | Carol | 404  |
 
 
   Scenario: space admin user deletes the project space