Fix cypress test failures/flakiness

[svogt0511]

Purpose

Closes: #838

To fix cypress test failures, eliminate test flakiness, restructure github actions to reuse common code. Ex. test failures in cypress/e2e/organization_admin/prefixes.test.ts, contacts.test.ts, dois.test.ts. It seems that cypress test flakiness has increased over time. Additionally, now it seems that cypress tests that often pass in the local dev environment, may fail pretty consistently in github actions.

A secondary goal was to restructure the github actions to share code that was used in more than one place.

Last, certain qunit tests were subject to failure because of a hardcoded year in 'expect'. This has been fixed.

Approach

After researching what might be causing these failures in github actions and trying various strategies, I found that the test failures, and some of the flakiness, was caused by trying to distribute the tests over several containers, and run those containers in parallel on the same machine in a github action. I read somewhere that this has been found not to work so well, so I removed it, and now the tests seem to run well both locally and in github actions.

The cypress-io/github-action offers the ability to run tests in parallel in order to shorten the the time it takes to run test suites. This is implemented in gihub actions by specifying a container matrix and using the 'parallel: true' flag, as can be seen here.

I hope to be able to take advantage of the parallelization feature with future upgrades. Also it should be noted that even though the test performance has improved, there is still some flakiness inherent in the Cypress test suite.

Some resources: Cypress Cloud - Parallelization, GitHub Actions - Run Tests in Parallel, Cypress Documentation - GitHub Actions

Open Questions and Pre-Merge TODOs

Learning

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)

Reviewer, please remember our guidelines:

• Be humble in the language and feedback you give, ask don't tell.
• Consider using positive language as opposed to neutral when offering feedback. This is to avoid the negative bias that can occur with neutral language appearing negative.
• Offer suggestions on how to improve code e.g. simplification or expanding clarity.
• Ensure you give reasons for the changes you are proposing.