Add some Chrome flags to make the browser more suitable for testing

[flotwig]

• Closes Add Chromium flag --disable-ipc-flooding-protection #5132
• Closes Add additional flags when running Chrome #3633

Moved --disable-dev-shm-usage to a new issue: #5336

User facing changelog

--disable-ipc-flooding-protection, --disable-backgrounding-occluded-window, --disable-breakpad, --password-store=basic, and --use-mock-keychain have been added to the list of arguments passed to Chrome on startup.

Additional details

This should improve the testing experience as described in the linked issues.

[cypress-bot]

Thanks for the contribution! Below are some guidelines Cypress uses when doing PR reviews.

• Please write [WIP] in the title of your Pull Request if your PR is not ready for review - someone will review your PR as soon as the [WIP] is removed.
• Please familiarize yourself with the PR Review Checklist and feel free to make updates on your PR based on these guidelines.

PR Review Checklist

Functionality

• Does the code work? Does it perform its intended function, the logic is correct, etc?
• Does the code guard against edge cases, invalid input, etc being entered? Are there tests for these?
• Is any code invoking memory leaks? Has performance been factored in?

Maintainability

• Is the code readable (too many nested 'if's are a bad sign.)
• Do names used for variables, methods, etc, describe their function?
• Is all the code easily understood? Are there relevant comments explaining?
• Have algorithms been documented in the code? Is there a link to an external document? (flowcharts, w3c, chrome, firefox)

Quality

• Is there a comment containing a link to the issue this is fixing (in tests and code)?
• Does the change reimplement code that would be better served by pulling in a well known module from the ecosystem?
• Is there any redundant or duplicate code?
• Are tests actually testing the code’s intended functionality? Is there a more comprehensive test that could be written?
• Are there any irrelevant comments left in the code?

User Experience

• Is the feature/bugfix self-documenting from within the product (is there a way to explain this feature in product, so it doesn’t rely on resources outside, like docs)?
• Are there any dead ends? Do we provide the end user with a way to fix their problem?

Internal

• Has the original issue been tagged with a release in ZenHub?

[bahmutov]

looks good - ran this PR on performance spec locally on Mac, and did not see warnings in Chrome's DevTools console any more

[jennifer-shehane]

@flotwig Does this not fix this Docker issue? #350

Also, can you add a 'why' to the user facing changelog? I know these are necessary, but there aren't really any reasons detailing why this was necessary - user changing behavior after this is in place. If must affect something - that is not explained.

[flotwig]

@flotwig Does this not fix this Docker issue? #350

No, it doesn't I don't think.

---

Re: the other Docker issue (#3633), adding --disable-dev-shm-usage would fix it. To be honest, the only reason I didn't add --disable-dev-shm-usage is because I don't really know what it does. But Puppeteer passes it and everything is fine, so I guess it can be added.

[bahmutov]

looks good

[mattempyre]

Why was --disable-dev-shm-usage removed?

[flotwig]

@mattempyre If you look at commit 7247dcf, adding it causes a bunch of tests to fail. Someone just needs to spend the time to figure out why these failures occur and an appropriate fix.

There is an open issue to add --disable-dev-shm-usage: #5336