Consider moving away from document.domain to adhere to better security practices

What would you like?

I would like to consider removing document.domain injection and making cy.visit() require a full navigation when a subdomain navigation occurs, changing the cookie APIs to set the cookie on the current domain (not super domain), and to better adhere to full origin specifications without strange exceptions when it comes to origin and domain nomenclature.

document.domain modification deprecation The origin specification

Why is this needed?

With the introduction of Chrome 119, Chrome and other browsers now bucket all requests to an origin server with a given Origin-Agent-Cluster key:

The browser will ensure that all pages from a given origin are either origin-keyed or they are not. This means that:

If the first page from an origin does not set the header, then no other pages from that origin will be origin-keyed, even if those other pages do set the header.
If the first page from an origin sets the header and is made origin-keyed, then all other pages from that origin will be origin-keyed whether they ask for it or not.

Cypress ran into this in it's own system tests in #29391 and we patched a work around internally (see thread on PR).

This means the Agent-Origin-Cluster header needs to be set on the first page request. However, this is difficult for Cypress for a few reasons:

Cypress only injects into cy.origin() or the Application Under Test (AUT). It is sometimes impossible to know when injection is going to be required in the future for a request that has already been sent to an origin server, which gives us two options:

We set Agent-Origin-Cluster: ?0 on every origin server page request, which is not only a bad security practice, but almost guarantees we will be continuing an uphill battle fighting browser security, which we don't want.
We remove document.domain injection, which would likely fix a slew of problems:
- Cookie management in the server becomes more deterministic and should solve #25806 as we no longer have to infer super domain cookies and can use normal browser nomenclature.
- Fixes cookies implicitly locally as requests would now attach correct cookies for given domain requests
  - For example, look at the following cypress spec:
```
  describe('cookies', () => {
    it('does not send cookie like expected', () => {
      cy.visit('https://example.cypress.io')
      // do a navigation to a sub domain
      cy.visit('https://docs.cypress.io')
      cy.setCookie('foo', 'bar', {
        domain: 'docs.cypress.io'
      }).then(async() => {
        // this does NOT send the foo=bar cookie as the host is example.cypress.io and the request is considered cross origin
        await fetch('docs.cypress.io')
      })
    })

    it('sends cookie like expected', () => {
      // run this in a fresh cypress instance to make sure top is reset
      cy.visit('https://docs.cypress.io')
      cy.setCookie('foo', 'bar', {
        domain: 'docs.cypress.io'
      }).then(async() => {
        // sends the foo=bar cookie
        await fetch('docs.cypress.io')
      })
    })
  })
```
    These tests have different behavior depending on the order they are run and which window.top domain is set first, which contrasts our best practices on test determinism. Adhereing closer to the browser specification and doing a document reload makes sure cookies are sent in the correct context.
  - Should allow us to change our cookie apies to set the cookie on the fully qualified domain and not the super domain (API breaking change), which better aligns with browser cookie api behavior which is more secure https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies/set
  - cy.origin() now becomes more clear, which needs to be used on any origin navigation and not odd exceptions like sub domain navigation.
  - Likely a lot of other issues are implicitly fixed by this, such as
    - https://github.com/cypress-io/cypress/issues/29445
    - https://github.com/cypress-io/cypress/issues/20784, see https://github.com/cypress-io/cypress/issues/20784#issuecomment-1573906437

Other

No response

cypress-io / cypress