Update sabre/dav to 3.3.0-alpha1

[DeepDiver1975]

Description

sabre/dav 3.3.0-alpha1 was released yesterday ... let's see how it works out for us

Motivation and Context

Some significant changes for us are in there - see https://github.com/sabre-io/dav/releases/tag/3.3.0-alpha1

How Has This Been Tested?

• requires full acceptance tests as executed by drone
• requires smashbox tests

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codecov]

Codecov Report

Merging #31644 into master will decrease coverage by 0.93%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master   #31644      +/-   ##
============================================
- Coverage     64.06%   63.12%   -0.94%     
+ Complexity    18634    18436     -198     
============================================
  Files          1176     1158      -18     
  Lines         70142    69256     -886     
  Branches       1267     1260       -7     
============================================
- Hits          44934    43721    -1213     
- Misses        24838    25166     +328     
+ Partials        370      369       -1

Flag	Coverage Δ	Complexity Δ
#javascript	52.39% <ø> (-0.45%)	0 <ø> (ø)
#phpunit	64.36% <100%> (-0.98%)	18436 <0> (-198)

Impacted Files	Coverage Δ	Complexity Δ
apps/dav/lib/Files/FilesHome.php	100% <100%> (ø)	12 <0> (ø)	⬇️
lib/private/Files/External/Auth/Builtin.php	0% <0%> (-100%)	1% <0%> (ø)
.../private/Files/External/Auth/Password/Password.php	0% <0%> (-100%)	1% <0%> (ø)
...ib/private/Files/External/StorageModifierTrait.php	0% <0%> (-100%)	1% <0%> (ø)
lib/private/Files/External/Auth/NullMechanism.php	0% <0%> (-100%)	1% <0%> (ø)
apps/dav/lib/CalDAV/Plugin.php	0% <0%> (-92.31%)	2% <0%> (-5%)
lib/private/Helper/EnvironmentHelper.php	33.33% <0%> (-66.67%)	3% <0%> (-1%)
lib/private/SystemConfig.php	44.44% <0%> (-55.56%)	14% <0%> (-4%)
.../Files/External/Auth/CoreAuthMechanismProvider.php	0% <0%> (-50%)	2% <0%> (ø)
lib/private/Files/External/VisibilityTrait.php	7.14% <0%> (-46.43%)	12% <0%> (ø)
... and 197 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update caed2fe...23d960d. Read the comment docs.

[phil-davis]

I fixed a \ that php-cs-fixer complained about.

Still has a fail for:

  Scenario: Download a file that exists in filecache but not storage fails with 404         # /drone/src/tests/acceptance/features/apiMain/external-storage.feature:49
    Given user "user0" has been created                                                     # FeatureContext::adminCreatesUserUsingTheAPI()
    And user "user0" has created a folder "/local_storage/foo3"                             # FeatureContext::userCreatesAFolder()
    And user "user0" has moved file "/textfile0.txt" to "/local_storage/foo3/textfile0.txt" # FeatureContext::userHasMovedFile()
    And file "foo3/textfile0.txt" has been deleted in local storage                         # FeatureContext::fileHasBeenDeletedInLocalStorage()
    When user "user0" downloads the file "local_storage/foo3/textfile0.txt" using the API   # FeatureContext::userDownloadsTheFileUsingTheAPI()
    Then the HTTP status code should be "404"                                               # FeatureContext::theHTTPStatusCodeShouldBe()
    And as "user0" the file "local_storage/foo3/textfile0.txt" should not exist             # FeatureContext::asTheFileOrFolderShouldNotExist()
      file "local_storage/foo3/textfile0.txt" expected to not exist (status code 200, expected 404) (Exception)

This test deletes a file directly from the underlying local storage folder. The file is gone when an attempt is made to download it (404). But the "exists" check does a bit different Sabre client request, and that is returning 200 - I guess that is coming out of the cache somewhere.
The test scenario was added last year by PR #28614

[DeepDiver1975]

This issue is related to a upstream change .... will dig deeper

[phil-davis]

Rebased here to get composer.json etc up-to-date.
Of course that did not magically fix the failing test. :(