WIP: Start pipeline on Jenkins push hook

What does this MR do?

When the Jenkins webhook was triggered, there is no way for users to see the status on the commit or MR right away. Users have to wait for Jenkins to call back on the API and initialize the pipeline. This MR starts a new pipeline and set the status to "pending" before the webhook executes. If the webhook execution fails, it will let the pipeline fail as well. It is up to Jenkins to pick up the pipeline and change the status depending on the build status. To do that Jenkins uses the commit statuses API

Related issues

Starting a pipeline with the webhook would probably fix the following issues:

• #34285 (closed)
• #29638
• #29509
• #3248 (closed)
• #1138 (closed)
• #15985 (closed)

We can build on top of it to address #33056 as well

Screenshots

When the webhook fails:

When the webhook is successful:

Decisions to make

The name of the commit status is currently hardcoded with "Jenkins Webhook". If the same name is not configured on Jenkins, the Pipeline will end up in a pending state that can not be resolved.

I can think of two possible solutions:

1. We keep the the webhook in a separate job and make it succeed when it is triggered successfully. This would make the pipeline succeed for a short while until Jenkins starts a new Job though.
2. We make the name configurable by adding a new field to the service. When users update GitLab they will have to change the configuration to match the name configured in Jenkins

Alternatives

After a discussion with @arturoherrero we found a few alternative approaches to solve the problem.

1. We create a temporary pipeline when the webhook was triggered and remove it once we get a callback from Jenkins. The description parameter we got from Jenkins does not matter in this case. The temporary pipeline shows the user that something is going on until Jenkins takes over. We probably need to hack this into the commit statuses endpoint
2. We create a pipeline with a specific description like Jenkins Webhook when the webhook was triggered. The description must match the configured name in Jenkins to make sure it can take over the same pipeline. We have to figure out what happens when multiple pipelines are running though. (This is the approach currently implemented in this MR)
3. We just create a new pipeline in case the webhook runs into an error. Until Jenkins calls the API users would still see Could not retrieve the pipeline status.
4. We introduce a new feature that can show the status of a webhook and don't use pipelines to indicate it.

We will explore those ideas in the upcoming days and add more description to it.

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team