merge ocdav into frontend

[butonic]

This PR moves the ocdav handler back into the frontend. This removes one usage of the go micro service.

[butonic]

it seems reva handles a leading // differently:

  Scenario: send PROPFIND requests to webDav endpoints with 2 slashes using the spaces WebDAV API                                 # /woodpecker/src/github.com/opencloud-eu/opencloud/tests/acceptance/features/coreApiAuth/webDavSpecialURLs.feature:155
    When user "Alice" requests these endpoints with "PROPFIND" to get property "d:href" about user "Alice"                        # AuthContext::theUserRequestsTheseEndpointsToGetOrSetPropertyAboutUser()
      | endpoint                                 |
      | //dav//spaces/%spaceid%/textfile1.txt    |
      | /dav//spaces/%spaceid%/PARENT/parent.txt |
      | /dav//spaces/%spaceid%/PARENT            |
      | //dav/spaces//%spaceid%//FOLDER          |
    Then the HTTP status code of responses on each endpoint should be "200,207,207,200" on OpenCloud or "207,207,207,207" on reva # FeatureContext::theHTTPStatusCodeOfResponsesOnEachEndpointShouldBeOcReva()
      Expected HTTP status codes: "200,207,207,200". Found HTTP status codes: "405,207,207,405"
      Failed asserting that false is true.

  Scenario: send PROPPATCH requests to webDav endpoints with 2 slashes                                                 # /woodpecker/src/github.com/opencloud-eu/opencloud/tests/acceptance/features/coreApiAuth/webDavSpecialURLs.feature:165
    When user "Alice" requests these endpoints with "PROPPATCH" to set property "d:getlastmodified" about user "Alice" # AuthContext::theUserRequestsTheseEndpointsToGetOrSetPropertyAboutUser()
      | endpoint                                 |
      | //webdav/textfile0.txt                   |
      | //dav//files/%username%/textfile1.txt    |
      | /dav//files/%username%/PARENT/parent.txt |
      | /webdav//PARENT                          |
      | //dav//files/%username%//FOLDER          |
    Then the HTTP status code of responses on each endpoint should be "200,200,400,400,200" respectively               # FeatureContext::theHTTPStatusCodeOfResponsesOnEachEndpointShouldBe()
      Expected HTTP status codes: "200,200,400,400,200". Found HTTP status codes: "405,405,400,400,405"
      Failed asserting that false is true.

[butonic]

@ScharfViktor the tests were expecting the wrong status codes. I corrected them and CI should now become green.

[aduffeck]

Should we introduce FRONTEND_OCDAV_* variables and deprecate the OCDAV_* ones for consistency?

[butonic]

I would rather aim for dropping the service prefix. @rhafer proposed that and since we are deploying only one process in the compose stack and two or three in the helm chart, I agree. In this case OCDAV_ would match the handler, so I think reusing them is fine.

IIRC @dragonchaser is trying to reduce the number of env vars as well, so he might have an opinion as well.