[stable33] test(cypress): Improve stability of cypress test suite by fixing several issues

[DerDreschner]

• Resolves: [CI] Cypress tests for live images very flaky #47307
• Related: [tests] Analysis of potential flaky e2e tests (AI generated) #62285

Summary

While stable34 upwards is being moved to Playwright, the older branches still rely on the Cypress end-to-end test suite. As we still need to support those versions, it's important to have a more reliable CI pipeline there as well (IMHO). For myself, the long runtime for all tests isn't a problem per-se - it's the unreliable test results, which makes auto-merge impossible and needs a lot of re-runs and manual force-merges... Which slows down the general development speed a lot.

To achieve that, I've used Claude Fable 5 with xhigh to find and fix the issues that make our cypress tests so unreliable under limited CPU resources (simulated that by reducing the available container resources to --cpus="0.2"). This PR is the result of all runs.

The following issues were fixed:

• Changed the defaultCommandTimeout from 4 to 10 seconds, as all 32 timeout failures across two analyzed CI runs hit exactly the 4000ms default, while none of the 28 timeouts already raised to ≥10s in the suite ever fired
• Raised the timeout for the cron.php call in files-external-failed.cy.ts, as the first cron run on a fresh instance takes ~71 seconds (measured — every later run needs ~250ms) and therefore blew cypress' 60 seconds execTimeout default; it runs in a before all hook, which isn't retried, so the whole suite got skipped
• Explicitly wait for long-running requests to benefit from the way higher request timeout instead of the defaultCommandTimeout
• Moved the testapp to apps-writable, as the changes to the e2e-test-server broke the custom apps-cypress folder since this PR - auto-detect the folder as it was apps_writable with this PR and changed to apps-writable with another PR later
• The checks for the Download button in the files-download.cy.ts and files_trashbin/files.cy.ts queried the exact match, which failed as it's actually Download: <filename>
• The headline check in the admin-settings_branding.cy.ts is ambiguous, as there is a hidden headline with the same text
• The default-app combobox check searched for the app names inside the <input role="combobox"> itself - impossible, since Vue 3's vue-select moved that role from the wrapper onto the input; it now asserts the deselect buttons instead
• Made systemtags/admin-settings.cy.ts retry-safe and self-contained: randomized tag names, each describe block creates its own tag via occ instead of inheriting it from the previous one, and the create test reloads per attempt - previously one slow-runner hiccup left the form dirty (testIsolation: false means retries don't reset state) and cascaded into six failures
• Hardened the file picker confirmation in FilesUtils.ts, as the confirm button is rendered disabled while the picker (re)loads its directory listing and clicking into that transition swallowed the click, so no COPY/MOVE request was sent at all; when navigating to the home root we additionally wait for the picker's own PROPFIND, as the button label switches to the root label before the picker's current directory follows (which copied into the wrong folder, deduplicated as … (1))
• Hardened action menu opening mechanism in FilesUtils.ts and filesVersionsUtils.ts, as the previous logic was prone to fail under different circumstances (the click firing before Vue attached the handler to the button, the DOM switched to aria-expanded="true" while the menu is still opening and the file list being re-rendered when a thumbnail/preview request is being finished)
• Versions test mechanism in filesVersionsUtils.ts is being hardened by setting explicit creation times via X-OC-MTime, as the versions could be created within the same second on slow runners, which means one of the versions will be ignored due to our internal mechanisms
• Versions test mechanism in filesVersionsUtils.ts is being hardened by reloading the page if the new share isn't visible (that can take some time under high CPU load)
• Fixed a wrong assertion in view_file-drop.cy.ts, as there could be multiple progress bars, some are present in the DOM but not visible (the upload picker and the file-drop view created one)
• Expect a picture in router-query.cy.ts, as the preview generation could fail or take too much time under high CPU load and there is a fallback mechanism to get the picture itself instead which the test doesn't honor
• Explicitly set the necessary state in admin-settings_default-app.cy.ts instead of implicitly expect that state to be there with the previous test finished (which isn't the case on re-tries or failed tests)
• Fixed the trashbin row assertions in files_trashbin/files.cy.ts, as fileId is assigned inside a .then() while the row selectors were built synchronously and therefore queried [data-cy-files-list-row-fileid="undefined"] whenever the upload chain hadn't resolved yet - reading it inside a cy.then() defers that until the value exists
• Made cy.mkdir idempotent by accepting the 405 that MKCOL answers for an already existing collection, as a retry re-runs the test body but not the data it created, so every attempt after the first failed during setup - and included the HTTP status in the error message, which previously hid the cause entirely.

The following issue is being fixed in this PR, but should be removed once the root cause is being fixed in other repositories:

• This PR contains a hardened login mechanism to ensure the login actually happened and there were no silent errors (e.g., a failed login POST, or a dead cached session that still passes the package's redirect-following validation) - remove once included upstream
• This PR contains a change to skip tests that might fail due to a known race-condition in the FilePicker module in nextcloud-dialogs which needs a fix there

Follow-up tasks

• Create a PR in https://github.com/nextcloud-libraries/nextcloud-e2e-test-server with the hardened login logic for cypress
• Remove the overwrite here once the hardened logic is available in the e2e-test-server itself
• Include the feedback for the PR in nextcloud-dialogs and backport it down as low as possible
• Remove the skip flag in the e2e tests once the nextcloud-dialogs fix is backported
• Create a separate PR for server issues found

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[susnux]

First look seems to be fine - waiting for CI.
But why so many unrelated changes? I mean all those:

- ..., () => {
+ ..., function () {

[DerDreschner]

But why so many unrelated changes? I mean all those:

- ..., () => {
+ ..., function () {

Those are necessary when using skipOnKnownFilePickerRace(this). The arrow functions used before doesn't have their own this context. But that's necessary so the Mocha.Context for the currently running test is available and passed to the skipOnKnownFilePickerRace function. See https://mochajs.org/features/arrow-functions/ for example:

If you do not need to use Mocha's context, lambdas should work.

but it isn't recommended for exactly the use-case we have here:

Passing arrow functions (aka “lambdas”) to Mocha is discouraged. Lambdas lexically bind this and cannot access the Mocha context.