etags of folders do not change when a file is restored

[phil-davis]

New test scenarios were added in core PR owncloud/core#37954

These are failing with files_primary_s3:

https://drone.owncloud.com/owncloud/files_primary_s3/1903/94/17

Feature: propagation of etags when restoring a version of a file

  Background:                                                                            # /var/www/owncloud/testrunner/tests/acceptance/features/apiWebdavEtagPropagation/restoreVersion.feature:4
    Given using OCS API version "2"                                                      # FeatureContext::usingOcsApiVersion()
    And using new DAV path                                                               # FeatureContext::usingOldOrNewDavPath()
    And user "Alice" has been created with default attributes and without skeleton files # FeatureContext::userHasBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles()

  Scenario Outline: Restoring a file changes the etags of all parents                                # /var/www/owncloud/testrunner/tests/acceptance/features/apiWebdavEtagPropagation/restoreVersion.feature:9
    Given user "Alice" has created folder "/upload"                                                  # FeatureContext::userHasCreatedFolder()
    And user "Alice" has created folder "/upload/sub"                                                # FeatureContext::userHasCreatedFolder()
    And user "Alice" has uploaded file with content "uploaded content" to "/upload/sub/file.txt"     # FeatureContext::userHasUploadedAFileWithContentTo()
    And user "Alice" has uploaded file with content "changed content" to "/upload/sub/file.txt"      # FeatureContext::userHasUploadedAFileWithContentTo()
    And user "Alice" has stored etag of element "/<element>"                                         # WebDavPropertiesContext::userHasStoredEtagOfElement()
    When user "Alice" restores version index "1" of file "/upload/sub/file.txt" using the WebDAV API # FilesVersionsContext::userRestoresVersionIndexOfFile()
    Then the etag of element "/<element>" of user "Alice" should have changed                        # WebDavPropertiesContext::etagOfElementOfUserShouldHaveChanged()

    Examples:
      | element    |
      |            |
        WebDavPropertiesContext::etagOfElementOfUserShouldHaveChanged The etag of element '/' of user 'Alice' was expected to change. The stored etag was '"5f768004cb142"' and got '"5f768004cb142"' from the response
        Failed asserting that '"5f768004cb142"' is equal to '"5f768004cb142"'.
      | upload     |
        WebDavPropertiesContext::etagOfElementOfUserShouldHaveChanged The etag of element '/upload' of user 'Alice' was expected to change. The stored etag was '"5f76802c1421c"' and got '"5f76802c1421c"' from the response
        Failed asserting that '"5f76802c1421c"' is equal to '"5f76802c1421c"'.
      | upload/sub |
        WebDavPropertiesContext::etagOfElementOfUserShouldHaveChanged The etag of element '/upload/sub' of user 'Alice' was expected to change. The stored etag was '"5f768053511c2"' and got '"5f768053511c2"' from the response
        Failed asserting that '"5f768053511c2"' is equal to '"5f768053511c2"'.

Note: these tests pass with user_ldap and encryption apps, and in core. They fail with all the S3 storages (ceph, scality...). So it looks like it is an S3-specific problem.

[phil-davis]

Added QA-team label to look at what to skip or adjust.

Then someone will need to look at the underlying problem.

[phil-davis]

@individual-it do you remember this being a known problem with S3 storage?

[phil-davis]

Tests are sorted out to demonstrate this issue. Removing QA-team labels.