feat: make cookies have sameSite key by default

[flotwig]

BREAKING CHANGE: modifies the shape of Cookie objects

• Closes Make adding sameSite value to objects yielded by cy.getCookie/setCookie/getCookies the default #6892

User facing changelog

• Values yielded by cy.setCookie, cy.getCookie, and cy.getCookies will now always contain a sameSite attribute.
• Removed experimentalGetCookiesSameSite configuration flag, since this behavior is now the default.

Additional details

How has the user experience changed?

PR Tasks

• Have tests been added/updated?
• Has the original issue been tagged with a release in ZenHub?
• Has a PR for user-facing changes been opened in cypress-documentation? docs: document experimentalGetCookiesSameSite removal  cypress-documentation#2918
• Have API changes been updated in the type definitions?
• Have new configuration options been added to the cypress.schema.json?

[cypress-bot]

Thanks for taking the time to open a PR!

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.
• Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

[cypress]

---

Test summary

7816 • 0 • 129 • 0

---

Run details

Project	cypress
Status	Passed
Commit	03c5ce4
Started	Jun 29, 2020 6:29 PM
Ended	Jun 29, 2020 6:37 PM
Duration	08:02 💡
OS	Linux Debian - 10.1
Browser	Multiple

View run in Cypress Dashboard ➡️

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[brian-mann]

What happens if a user still uses experimentalGetCookiesSameSite in the config even though it's been removed?

Should they get a warning or should it error or silently do nothing?

[flotwig]

I think that since users with experimentalGetCookiesSameSite enabled will not experience a change in behavior, we don't need to add a deprecation warning at runtime. The migration guide will presumably document that this config option can be removed, and we should probably comment on the closed issues that this is no longer "experimental", and the flag is no longer necessary.

[brian-mann]

I think in this case that's probably fine, but since we're doing the experimental* pattern more frequently now it makes me wonder what our best practice should be. I'm actually on the side that we should hard error and throw and tell them this option has been removed.

I think that approach is much better than to silently pass because anyone looking at the code later will be sufficiently confused - won't be able to find the option anywhere in the docs, and will wonder if this is actually taking effect anywhere. Throwing forces the user to update their code, but it's the cleanest way to communicate the intention. Additionally, imagine if we had a situation where the options of the experimental* feature change to have new official meaning when it gets released.

I can think of a few other scenarios but those are the ones off the top of my head. I believe we already have logic in config to notify the user of renamed / removed properties. I'd also be okay with a deprecation notice, but unless people literally read their stdout they won't see it.

[flotwig]

I guess it's either make the user pay the cost now, by forcing them to update their config, or pay the cost later, by potentially confusing users that have not read the migration guide/seen the issue comment telling them to remove the config option.

Adding a deprecation notice to stdout sounds like a decent compromise between the two that will help make the 5.x upgrade easier, so that's what I'll do for this PR.

[brian-mann]

Okay cool. Use the existing config warning/deprecation machinery.

[brian-mann]

See the discussion here: #7790 (comment)

[brian-mann]

I think the convention when listing versions is to say in Cypress version x.x.x

[flotwig]

This was the only prior art I could find, which also isn't that:

cypress/packages/server/lib/errors.js

Lines 140 to 141 in c00f6cd

	Note: In Cypress 4.0, Canary must be launched as \`chrome:canary\`, not \`canary\`.

[jennifer-shehane]

In our migration guide we usually say Cypress 5, so as not to be restricted of it only applying to Cypress 5.0.0 and not to 5.1.0, etc.