This changes used worker from `BuildProcessWorker`
to `PipelineProcessWorker` to make pipeline
processing much simpler. We process `pipeline_id`,
based on some triggers.

Currently, some of the jobs with `needs:`
would be processed in stages, it means
that `when:` for such jobs would not be
respected.

This changes the behavior to have a separate
execution paths for jobs with `needs:`.

This implements the support for `needs:` keyword
as part of GitLab CI. That makes some of the jobs
to be run out of order.

Prepares us for upgrade to Rails 5.2

Introduces the concept of Prerequisites for a CI build.
If a build has unmet prerequisites it will go through the
:preparing state before being made available to a runner.

There are no actual prerequisites yet, so current
behaviour is unchanged.

Introduces a new status for builds between :created and :pending
that will be used when builds require one or more prerequisite
actions to be completed before being picked up by a runner
(such as creating Kubernetes resources before deploying).

The existing :created > :pending transition is unchanged, so
only builds that require preparation will use the :preparing
status.

In a few models we define ActiveRecord enums that are redefined in EE
using the following pattern:

    enum :some_enum, {
      ...
    }.merge(EE_ENUM_VALUES)

This particular approach is problematic to deal with, because it
requires that we `prepend` and EE module _before_ defining the enum.
This typically translates to the `prepend` being the first line in the
model in EE, but this can easily lead to merge conflicts when developers
add more `include` and/or `prepend` lines.

As part of https://gitlab.com/gitlab-org/gitlab-ee/issues/8244 and
https://gitlab.com/gitlab-org/gitlab-ee/issues/8241 we are moving
`prepend` to the last line in a file, reducing the chances of running
into merge conflicts. This poses a bit of a problem with the pattern
above, because this pattern does not allow us to move the `prepend`
further down a file.

To resolve this problem, we simply move the Hash value of the enum to a
separate class method. This method is defined in a separate module where
necessary, allowing us to use it like so:

    enum :failure_reasons, ::SomeModelEnums.failure_reasons

The method in turn is defined in a very straightforward manner:

    module SomeModelEnums
      def self.failure_reasons
        {
          ...
        }
      end
    end

This makes it easy for EE to add values without requiring the `prepend`
to be placed before the `enum` is defined.

For more information, see the following issues and merge requests:

* https://gitlab.com/gitlab-org/gitlab-ee/issues/8244
* https://gitlab.com/gitlab-org/gitlab-ee/issues/8241
* https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8424

The soft-archived builds cannot be run after some deadline time.
The intent is to aggressively recycle old builds after sometime.

This whitelists all existing offenses for the various CodeReuse cops, of
which most are triggered by the CodeReuse/ActiveRecord cop.

Partially addresses #47424.

Enum in Rails 5 does not map nil values - IOW nil value remains nil,
even if there is a key with nil value in the enum definition.

This commit overrides the underlying Enum methods so nil value is
still mapped. This solution is far from being ideal: it uses dynamic
definition of methods which introduces more magic/confusion
into the codebase.

It would be better to get rid of the nil value in enums.

methods

Includes Presentable module into CommitStatus. This fixes presenter
methods being called on those classes.

Closes #46177

This reverts commit 4f2cdb51.

This makes grouping on version number available. In general I'd like to
group based on MAJOR.MINOR version numbers for Gitaly.

Currently we still need to run EnsureStageService within a transaction,
because when it runs within in a transaction we are going to stick to
the primary database when using database load balancing. Extracting this
out of the transaction makes it possible to hit into problems with
replication lag in pipeline commit status API, which can cause a lot of
trouble.