[tests-only][full-ci] Test: Include apiCollaboration test suite to run in k8s

[anon-pradip]

Description

This PR adds WOPI collaboration test suite to run in k8s CI pipeline.

1. wopiCollaborationService needs ocis_url parameter
Because in k8s, OCIS runs at a different URL than the hardcoded OCIS_URL constant. The collaboration service needs to know where OCIS is to communicate with it.

2. Patch collaboration/deployment.yaml to use {{ $officeSuite.wopiSrc }}
In k8s, the WOPI source URL is not a fixed http://*:9300 — it varies per office suite (collabora, fakeoffice, onlyoffice). Using the Helm template variable makes it dynamic.

3. Remove values.schema.json before helm install
The schema validation was blocking extra configs needed for WOPI/fakeoffice setup in k8s. Removing it allows the custom deployment-values.yaml overrides to pass through.

4. enableAppsIntegrationK8s
WOPI requires appsIntegration to be enabled in the Helm values — it's off by default.

5. exposeExternalServersK8s
Collabora, fakeoffice, and onlyoffice run as Drone services (outside k8s). This bridges them into the k8s cluster so OCIS pods can reach them.

6. exposeNodePortsK8s
The collaboration services running inside k8s need to be reachable from outside (i.e., from the test runner). NodePort exposes them on the k3s node.

Changes made in tests/acceptance/features/apiCollaboration/wopi.feature:

1. Removed $ from WOPISrc URL regex patterns — the old pattern required the URL to end after the file ID ([a-fA-F0-9]{64}$), but in k8s the URL has additional query parameters after it, so the $ end anchor was too strict.
2. Expanded app name matching — changed app=FakeOffice to app=(FakeOffice|Collabora|OnlyOffice) because in k8s all three office suites are registered and any one of them could be returned.

Passing build:

• https://drone.owncloud.com/owncloud/ocis/52004/15/18

Related Issue

• Part of: [QA] [k8s] Fix failing tests on suites running on k8s #11658

Motivation and Context

How Has This Been Tested?

• test environment:
• Locally
• CI

Screenshots (if appropriate):

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)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud