Bringing in the DB migration and some light changes for CE classes

In certain cases, GitLab can miss a PostReceive invocation the first
time a branch is pushed. When this happens, the "branch created" hooks
are not run, which means various features don't work until the branch
is deleted and pushed again.

This MR changes the `Git::BranchPushService` so it checks the cache of
existing branches in addition to the `oldrev` reported for the branch.
If the branch name isn't in the cache, chances are we haven't run the
service yet (it's what refreshes the cache), so we can go ahead and
run it, even through `oldrev` is set.

If the cache has been cleared by some other means in the meantime, then
we'll still fail to run the hooks when we should. Fixing that in the
general case is a larger problem, and we'd need to devote significant
engineering effort to it.

There's a chance that we'll run the relevant hooks *multiple times*
with this change, if there's a race between the branch being created,
and the `PostReceive` worker being run multiple times, but this can
already happen, since Sidekiq is "at-least-once" execution of jobs. So,
this should be safe.

Commit messages are not processed for references to issues when
creating the default branch on push. This was expected
behavior (probably to avoid performance problems when first pushing a
repository with thousands of commits). However, this is not an issue
because we always limit the number of commits to process to 100
regardless of whether we are creating the default branch or not.

Remote mirrors were only being updated after pushes to branches, not
tags. This change consolidates the functionality into
Git::BaseHooksService so that both tags and branches will now update
remote mirrors.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/51240

Fixes #60425

This adds a limitation that we will try to create pipeline
for at most 4 first changes (branches and tags).

This does not affect processing of Pipelines for Merge Requests,
as each updated MR will have associated pipeline created.

Previously the raw push option Array was sent to Pipeline::Chain::Skip.

This commit updates this class (and the chain of classes that pass the
push option parameters from the API internal `post_receive` endpoint to
that class) to treat push options as a Hash of options parsed by
GitLab::PushOptions.

The GitLab::PushOptions class takes options like this:

    -o ci.skip -o merge_request.create -o merge_request.target=branch

and turns them into a Hash like this:

    {
      ci: {
        skip: true
      },
      merge_request: {
        create: true,
        target: 'branch'
      }
    }

This now how Pipeline::Chain::Skip is determining if the `ci.skip` push
option was used.