Remove snyk as a blocking CI step

[kieckhafer]

Snyk frequently comes up as a blocking step in our CI process.

This doesn't fully make sense, especially since the majority of the time, what Snyk flags is already in develop branch of Reaction, and not introduced by the PR being flagged.

This causes unneeded frustration for developers, having PR's blocked by things they have no control over.

We should remove SNYK as a blocking CI step, and use it for reference to improve the app instead. We can also look into adding different apps that might be easier to work with: Automation via Zapier, If This Than That, etc.

[kieckhafer]

@focusaurus @aldeed @bt3gl @spencern Does this seem like SNYK should only be running if package.json is different than the published branch? I think that's what we want, so maybe this isn't working? https://github.com/reactioncommerce/reaction/blob/ci-kieckhafer-addByChangedFileLinting/.circleci/config.yml#L339

[aldeed]

@kieckhafer Yes I'm not sure if it's still using that check or if it's some integration on the Snyk side now. The best would be to test by changing some file (not package.json) in a fork to your personal GitHub, and PR that back.

That said, we had discussed this and thought in general that we should remove Snyk entirely from CI checks. The reason is because Snyk check results change randomly, depending on when security bugs are found and reported. So it makes more sense to run them as a scheduled job rather than triggered by CI. They are already scanned daily and results are sent to those who are subscribed on Snyk.

[kieckhafer]

Closed via #5403