This reverts commit 95138a9c, reversing
changes made to 66aad16d.

So the method can be used in a `create_table` block. There is a new Rubocop style cop that requires the usage of `datetime_with_timezone`.

This ensures we make maximum one call per feature per request.

See
https://github.com/jnunemaker/flipper/blob/v0.10.2/docs/Optimization.md#memoizing-middlewareSigned-off-by: NRémy Coutable <remy@rymai.me>

Start of the new navigation by redesigning just the top navigation menu.
This is only shown when a cookie is set.

Part of #32794

+ Set defaults correctly only for when not in production or staging
+ set ENV['prometheus_multiproc_dir'] in config/boot.rb instead of config.ru

Test prometheus metrics unmemoized

We removed calls from our code to Rugged::Repository#fetch_attributes:
<https://gitlab.com/gitlab-org/gitlab_git/commit/340e111e040ae847b614d35b4d3173ec48329015>

However, we didn't remove calls from within Linguist. This method is only called
when calculating the languages for a repository on the Charts page:
<https://github.com/github/linguist/blob/v4.7.0/lib/linguist/lazy_blob.rb#L33-L36>

We can safely use our own Gitlab::Git::Attributes here. On staging, for the
GitLab CE repo, this makes the calculation take about a third of the time:

    # Before
    Benchmark.realtime do
      Linguist::Repository.new(repository.rugged,
                               repository.rugged.head.target_id).languages
    end
    #=> 23.67193900188431

    # After
    Benchmark.realtime do
      Linguist::Repository.new(repository.rugged,
                               repository.rugged.head.target_id).languages
    end
    #=> 8.945212290156633

Let the backend do the translation.

Adds support for https://gitlab.com/gitlab-com/infrastructure/issues/57

This instrumentation isn't needed strictly for performance measurements, but
just to see which controller actions call this method at all. See
<https://gitlab.com/gitlab-org/gitlab-ce/issues/30224#note_32306159> for more
details.

This reverts merge request !12036

Background migrations can be used to perform long running data
migrations without these blocking a deployment procedure.

See MR https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11854 for
more information.