chore(e2e): simplify Cypress record key usage

[rusackas]

SUMMARY

The Cypress Record Key on the repo secrets is no longer base-64 encoded, so there's no need for this decoding. We also might as well just call it the CYPRESS_RECORD_KEY everywhere to match the name of the repo secret, for sanity's sake.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[mistercrunch]

Do we not want that pop? In the case of running off the repo where the env var is always present, it may always disregard the use_dashboard param effectively

[rusackas]

¯_(ツ)_/¯ I wasn't sure... I'll add it back in... it certainly doesn't hurt.

[michael-s-molina]

@rusackas I don't know if this PR is the source for the problem but we can execute Cypress anymore for release branches such as 4.0. This is problematic because we need the whole suite of tests when pushing to release branches in order to check if the release is good to go.

Opening Cypress...
  Your Record Key b9c81...2394a is not valid with this projectId: ud5x2f
  
  It may have been recently revoked by you or another user.
  
  Please log into the Dashboard to see the valid Record Keys.
  
  https://on.cypress.io/dashboard/projects/ud5x2f

[rusackas]

It should run the tests on those branches, just not with the cypress dashboard enabled. I rotated the key, and changed the action to use the repos secret, so you may have to pull this in as a cherry?

[michael-s-molina]

It was a little tricky, because 4.0 structure is completely different than master, but I was able to cherry-pick the necessary changes to make Cypress work again.