add strictSSL query param toggle to [coverity]

[calebcartwright]

Close #3334

As detailed in #3334, Coverity has a cert chain issue which prevents us from being able to render our Coverity badges (internally, we get Inaccessible: unable to verify the first certificate errors on cert chain issues, the badges render as inaccessible). We've seen this with a couple other services (or instances of self-hosted tools, like #1956)

Ideally the upstream providers would resolve, but our Coverity badge users have expressed understandable concern around the timeframe for if/when Coverity (Synopsys) would be able to resolve this. We receive the cert verification error on both Node 8.x and 10.x so I believe it's an issue that we'll need to address.

This proposed solution adds a new a new query param disableStrictSSL that will allow the user to opt-in to disabling the strict ssl check, thus re-enabling Coverity badges. It's the same solution we seem to be going with for Jenkins

Default behavior (strict ssl check enabled per request's defaults):
https://shields-staging-pr-3336.herokuapp.com/coverity/scan/3997.svg

https://shields-staging-pr-3336.herokuapp.com/coverity/scan/3997.svg?disableStrictSSL

[shields-ci]

	Warnings
⚠️	This PR modified service code for coverity but not its test code. That's okay so long as it's refactoring existing code.

	Messages
📖	✨ Thanks for your contribution to Shields, @calebcartwright!

Generated by 🚫 dangerJS against 4bf6f42

[chris48s]

With Jenkins CI, I think its right for this to be user-configurable because its not a centralised service. We should assume that usually we can contact a jenkins instance with strictSSL on, but some people may be running an instance where there is an SSL cert issue that warrants turning it off. In that case they've got an option.

Coverity is different because its a centralised service. We know we're going to get an SSL error attempting to call https://scan.coverity.com/ in all cases (at leats until the cert changes upstream). There is no user who doesn't need to add ?disableStrictSSL to fix their badge, so I think in this case we should just disableStrictSSL by default, as opposed to being broken by default.

[calebcartwright]

That works for me 👍

[shields-deployment]

This pull request was merged to master branch. This change is now waiting for deployment, which will usually happen within a few days. Stay tuned by joining our #ops channel on Discord!

After deployment, changes are copied to gh-pages branch: