e2e: split feature files (#175)

Signed-off-by: Francesco Ilario <filario@redhat.com>
Co-authored-by: Andy Sadler <ansadler@redhat.com>

e2e/features/restapi/create.feature

@@ -0,0 +1,15 @@
+Feature: Create workspaces via REST API
+
+  @skip
+  Scenario: users can create a new workspace
+
+  Scenario: user requests a private workspace
+    Given An user is onboarded
+    When  The user requests a new private workspace
+    Then  A private workspace is created
+
+  Scenario: user requests a community workspace
+    Given An user is onboarded
+    When  The user requests a new community workspace
+    Then  A community workspace is created
+

e2e/features/restapi/delete.feature

@@ -0,0 +1,7 @@
+Feature: Delete workspaces via REST API
+
+  @skip
+  Scenario: users can delete owned workspaces
+
+  @skip
+  Scenario: users cannot delete default workspace

e2e/features/restapi/update.feature

@@ -1,7 +1,4 @@
-Feature: Create, update, and delete workspaces via REST API
-
-  @skip
-  Scenario: users can create a new workspace
+Feature: Update workspaces via REST API
 
   Scenario: users can update their workspaces' visibility
     Given An user is onboarded
@@ -11,9 +8,14 @@ Feature: Create, update, and delete workspaces via REST API
 
   @skip
   Scenario: users can not update visibility of non-owned workspaces
+
+  Scenario: visibility changes from private to community
+    Given A private workspace exists for an user
+    When  The owner changes visibility to community
+    Then  The workspace is readable for everyone
 
-  @skip
-  Scenario: users can delete owned workspaces
+  Scenario: visibility changes from community to private
+    Given A community workspace exists for an user
+    When  The owner changes visibility to private
+    Then  The workspace is readable only for the ones directly granted access to
 
-  @skip
-  Scenario: users cannot delete default workspace

e2e/features/workspaces.feature

@@ -5,26 +5,6 @@ Feature: Workspace lifecycle
     Then Default workspace is created for them
     And  The workspace visibility is set to "private"
 
-  Scenario: workspace request a private workspace
-    Given An user is onboarded
-    When  The user requests a new private workspace
-    Then  A private workspace is created
-
-  Scenario: workspace request a community workspace
-    Given An user is onboarded
-    When  The user requests a new community workspace
-    Then  A community workspace is created
-
-  Scenario: visibility changes from private to community
-    Given A private workspace exists for an user
-    When  The owner changes visibility to community
-    Then  The workspace is readable for everyone
-
-  Scenario: visibility changes from community to private
-    Given A community workspace exists for an user
-    When  The owner changes visibility to private
-    Then  The workspace is readable only for the ones directly granted access to
-
   Scenario: role is set on workspace for owner user 
     When A workspace is created for an user
     Then The owner is granted admin access to the workspace