Support silent mode: Return early in `Integration#async_execute` and `Integrations::ExecuteWorker`

From #409662 (comment 1402570209)

Most of our integrations use Gitlab::HTTP, but there are a handful that don't. For example Asana and GitHub integrations use Faraday currently &8029.

We can take a similar approach as to what's been suggested for webhooks #393639 (comment 1402518031) where we prevent Integrations::ExecuteWorker from being queued when silent mode is enabled (probably by returning early in Integration#async_execute), and also return early in that worker to catch any that were queued earlier from executing. That would block integrations from being triggered in the first instance, rather than having them error later when making the POST.

There are some integrations that function slightly differently, for example, our Jira integration can be configured to let people view Jira issues in GitLab.

My understanding of silent mode (based on !120392 (merged)) is a GET request is permitted. So Jira issues should continue to display in GitLab during silent mode, as this feature makes GET requests to the Jira API. @sranasinghe is this understanding correct?

But POST requests (like when we POST to the Jira API when someone mentions a Jira issue in an issue, MR, comment, or commit) would fail as the client inherits from Gitlab::HTTP which would block the POST request !120392 (merged).

So that leaves a risk of integrations that:

• Do not use Gitlab::HTTP (because we use a gem that uses a different library for the request) AND
• Have functionality outside of the normal integration trigger flow.

I can't find any instances of these. As far as I can see all integrations that use other HTTP clients (like Discord, GitHub, Asana) use the normal integration trigger flow only, and would be suppressed from being triggered alongside all normal integrations if we put some early returns in Integration#async_execute and Integrations::ExecuteWorker mentioned above.