[Tests-Only] Allow up to 9 seconds delay in setTimeout API tests

[phil-davis]

Description

Last night the drone agent that ran the core API tests with encryption was running slower than normal. We got fails like:

https://drone.owncloud.com/owncloud/encryption/1356/41/16

Scenario Outline: set timeout over the maximum on folder                                             # /var/www/owncloud/testrunner/tests/acceptance/features/apiWebdavLocks2/setTimeout.feature:65
    Given using <dav-path> DAV path                                                                    # FeatureContext::usingOldOrNewDavPath()
    And parameter "lock_timeout_default" of app "core" has been set to "<default-timeout>"             # AppConfigurationContext::serverParameterHasBeenSetTo()
    And parameter "lock_timeout_max" of app "core" has been set to "<max-timeout>"                     # AppConfigurationContext::serverParameterHasBeenSetTo()
    When user "Alice" locks folder "PARENT" using the WebDAV API setting following properties          # WebDavLockingContext::lockFileUsingWebDavAPI()
      | lockscope | shared    |
      | timeout   | <timeout> |
    And user "Alice" gets the following properties of folder "PARENT" using the WebDAV API             # WebDavPropertiesContext::userGetsPropertiesOfFolder()
      | propertyName    |
      | d:lockdiscovery |
    Then the value of the item "//d:timeout" in the response should match "<result>"                   # WebDavPropertiesContext::assertValueOfItemInResponseRegExp()
    When user "Alice" gets the following properties of folder "PARENT/CHILD" using the WebDAV API      # WebDavPropertiesContext::userGetsPropertiesOfFolder()
      | propertyName    |
      | d:lockdiscovery |
    Then the value of the item "//d:timeout" in the response should match "<result>"                   # WebDavPropertiesContext::assertValueOfItemInResponseRegExp()
    When user "Alice" gets the following properties of folder "PARENT/parent.txt" using the WebDAV API # WebDavPropertiesContext::userGetsPropertiesOfFolder()
      | propertyName    |
      | d:lockdiscovery |
    Then the value of the item "//d:timeout" in the response should match "<result>"                   # WebDavPropertiesContext::assertValueOfItemInResponseRegExp()

    Examples:
      | dav-path | timeout      | default-timeout | max-timeout | result                    |
      | old      | second-600   | 120             | 3600        | /Second-(600|59[5-9])$/   |
        item "//d:timeout" found with value "Second-594", expected to match regex pattern: "/Second-(600|59[5-9])$/"
        Failed asserting that 'Second-594' matches PCRE pattern "/Second-(600|59[5-9])$/".
      | old      | second-600   | 99999           | 3600        | /Second-(600|59[5-9])$/   |
        item "//d:timeout" found with value "Second-594", expected to match regex pattern: "/Second-(600|59[5-9])$/"
        Failed asserting that 'Second-594' matches PCRE pattern "/Second-(600|59[5-9])$/".
      | old      | second-10000 | 120             | 3600        | /Second-(3600|359[5-9])$/ |
      | old      | second-10000 | 99999           | 3600        | /Second-(3600|359[5-9])$/ |
        item "//d:timeout" found with value "Second-3594", expected to match regex pattern: "/Second-(3600|359[5-9])$/"
        Failed asserting that 'Second-3594' matches PCRE pattern "/Second-(3600|359[5-9])$/".
      | old      | infinite     | 120             | 3600        | /Second-(3600|359[5-9])$/ |
        item "//d:timeout" found with value "Second-3594", expected to match regex pattern: "/Second-(3600|359[5-9])$/"
        Failed asserting that 'Second-3594' matches PCRE pattern "/Second-(3600|359[5-9])$/".
      | old      | infinite     | 99999           | 3600        | /Second-(3600|359[5-9])$/ |
        item "//d:timeout" found with value "Second-3594", expected to match regex pattern: "/Second-(3600|359[5-9])$/"
        Failed asserting that 'Second-3594' matches PCRE pattern "/Second-(3600|359[5-9])$/".
      | new      | second-600   | 120             | 3600        | /Second-(600|59[5-9])$/   |
        item "//d:timeout" found with value "Second-593", expected to match regex pattern: "/Second-(600|59[5-9])$/"
        Failed asserting that 'Second-593' matches PCRE pattern "/Second-(600|59[5-9])$/".
      | new      | second-600   | 99999           | 3600        | /Second-(600|59[5-9])$/   |
        item "//d:timeout" found with value "Second-594", expected to match regex pattern: "/Second-(600|59[5-9])$/"
        Failed asserting that 'Second-594' matches PCRE pattern "/Second-(600|59[5-9])$/".
      | new      | second-10000 | 120             | 3600        | /Second-(3600|359[5-9])$/ |
        item "//d:timeout" found with value "Second-3594", expected to match regex pattern: "/Second-(3600|359[5-9])$/"
        Failed asserting that 'Second-3594' matches PCRE pattern "/Second-(3600|359[5-9])$/".
      | new      | second-10000 | 99999           | 3600        | /Second-(3600|359[5-9])$/ |
        item "//d:timeout" found with value "Second-3594", expected to match regex pattern: "/Second-(3600|359[5-9])$/"
        Failed asserting that 'Second-3594' matches PCRE pattern "/Second-(3600|359[5-9])$/".
      | new      | infinite     | 120             | 3600        | /Second-(3600|359[5-9])$/ |
        item "//d:timeout" found with value "Second-3594", expected to match regex pattern: "/Second-(3600|359[5-9])$/"
        Failed asserting that 'Second-3594' matches PCRE pattern "/Second-(3600|359[5-9])$/".
      | new      | infinite     | 99999           | 3600        | /Second-(3600|359[3-9])$/ |

The agent was so slow that the check of the lock timeout happened more than 5 seconds later. The test results were expecting a value within 5 seconds of the actual lock timeout. The results were just 6 or 7 seconds difference.

Also, everything runs slower with encryption, so probably we are getting near this 5-second allowance quite often anyway.

This PR expands it to 9 seconds. That does not effect the validity of the test scenarios, and it is a practical way to make this pass 99.99% of the time (without trying to refactor a heap of code to do extra real-time calculations...)

How Has This Been Tested?

CI

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Database schema changes (next release will require increase of minor version instead of patch)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:
• Changelog item, see TEMPLATE