Return "Connectivity Error" if a self-signed certificate exists

What does this MR do and why?

Customer Support have been contacted by customers where they made use of a corporate network appliance that performs SSL inspection.

Related issue: Self-hosted cloud activation fails when SSL Dee... (#384538)

SSL inspection can overwrite an existing certificate chain, to instead show the network appliance as the issuer. Best practice indicates that to avoid "certificate warnings", all hosts should receive and "trust" the appliance's root CA. In enterprise, this is typically rolled out to workstations through GPO, automation or browser policies to trust the certificate. If a user does not put the appliance's certificate in the GitLab server's /etc/gitlab/trusted-certs folder, cloud activation might fail. A workaround is to also allow an exception/bypass to "customers.gitlab.com".

If this failure occurs, the current behaviour returns a generic An error occurred while adding your subscription response, which does not provide a hint towards the problem. Customer Support has had to request the user re-attempt the process, capture the graphql response output, and return the response. When captured, graphql returns:

[{"data":{"gitlabSubscriptionActivate":{"errors":["SSL_connect returned=1 errno=0 state=error: certificate verify failed (self signed certificate in certificate chain)"],"license":null,"__typename":"GitlabSubscriptionActivatePayload"}}}]

This MR updates behaviour in graphQL to consider an SSL error as a "connectivity error", and return that response: Cannot activate instance due to a connectivity issue. The documentation has also been updated as part of this MR to include an additional note, advising to check this and add the appliance certificate to the GitLab Server.

Screenshots or screen recordings

Before	After

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

To fully replicate this setup, I have deployed an Arista Untangle VM which provides a 14-day trial of "SSL Inspection". My GDK instance was deployed "behind" the Arista firewall, and for testing purposes, SSL inspection was enabled/disabled.

Once enabled, attempting to use a cloud activation license will return the connectivity error response.

Examples of the process are provided below:

On GitLab's master branch (SSL Inspection Enabled)	On this MR's branch (SSL Inspection Enabled)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.