As per https://gitlab.com/gitlab-org/gitlab-ce/issues/46043, project
templates should be squashed before updating, so that repositories
created from these templates don't include the full history of the
backing repository.

This will avoid Danger to suggest a database review for files inside
db/fixtures

- Adds UI to configure in group and project settings
- Removes notification configuration for users when
disabled at group or project level

Previously, the API to retrieve discussions from merge requests often
generated hundreds of Gitaly calls to determine whether a system note
should be shown to the user. It did this by:

1. Rendering the Markdown
2. Extracting cross-references from the Markdown
3. For cross-references that were commits, a Gitaly FindCommit RPC
   would be issued to validate that the commit exists.

The last step is unnecessary because we don't need to display a commit
if the user doesn't have access to the project in the first place.

`RendersNotes#prepare_notes_for_rendering` is already used in
`MergeRequestsController`, which is why we don't see N+1 Gitaly calls
there. We use it here to optimize the note redaction process.

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

This was added in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31789

CE-specific changes for:
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/15129Co-Authored-By: NAlex Kalderimis <akalderimis@gitlab.com>
Co-Authored-By: NLuke Duncalfe <lduncalfe@eml.cc>

- refactor Knative and Prometheus

This introduces several changes, but these are all just ported from the
EE project.

This change adds a new counter 'cycle_analytics_views' to the usage data
metrics to count the page views for cycle analytics show page.

We don't use phase restarts, as we use `preload_app`:
https://github.com/puma/puma/blob/master/README.md#clustered-mode
`:puma_phase` values will always be zero.

This makes to limit `needs:` to 5 by default.
Allow to increase the limit to 50 with disable of FF.

Source Code Usage Ping for Create SMAU

This makes us to expand variables only when needed,
instead of requesting all variables each time.

This specifically helps in situation when explicit name
of `environment: production` is used.

Previously each tag in a push would invoke the Gitaly `FindAllTags` RPC
since the tag cache would be invalidated with every tag.

We can eliminate those extraneous calls by expiring the tag cache once
in `PostReceive` and taking advantage of the cached tags.

Relates to https://gitlab.com/gitlab-org/gitlab-ce/issues/65795

This changes the `needs:` logic to require
that all jobs to be present. Instead of skipping
do fail the pipeline creation if `needs:` dependency
is not found.

Since we are unsure what would be the behavior of `stage:`
when we work on DAG. Let's make `stage:` to be required
today with `needs:`.

This commit reduces I/O load and memory utilization during PostReceive
for the common case when no project hooks or services are set up.

We saw a Gitaly N+1 issue in `CommitDelta` when many tags or branches
are pushed. We can reduce this overhead in the common case because we
observe that most new projects do not have any Web hooks or services,
especially when they are first created. Previously, `BaseHooksService`
unconditionally iterated through the last 20 commits of each ref to
build the `push_data` structure. The `push_data` structured was used in
numerous places:

1. Building the push payload in `EventCreateService`
2. Creating a CI pipeline
3. Executing project Web or system hooks
4. Executing project services
5. As the return value of `BaseHooksService#execute`
6. `BranchHooksService#invalidated_file_types`

We only need to generate the full `push_data` for items 3, 4, and 6.

Item 1: `EventCreateService` only needs the last commit and doesn't
actually need the commit deltas.

Item 2: In addition, `Ci::CreatePipelineService` only needed a subset of
the parameters.

Item 5: The return value of `BaseHooksService#execute` also wasn't being
used anywhere.

Item 6: This is only used when pushing to the default branch, so if
many tags are pushed we can save significant I/O here.

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

Fic

Standardize punctuation and format

Querying all counts for the different search results in the same request
led to timeouts, so we now only calculate the count for the *current*
search results, and request the others in separate asynchronous calls.

In the job log adds a highlight when hovering
the collapsible line

Previously imports would fail if a merge request note included a
suggestion with an
`ActiveRecord::HasManyThroughCantAssociateThroughHasOneOrManyReflection`
exception.

This was happening because suggestions were listed as a descendant of
merge requests, but this doesn't work because suggestions are directly
associated with notes, not merge requests, and that association is lost.
Rails also disallows creating intializing a has_many association through
a different object.

We fix this by making `suggestions` a child of `notes` within a merge
request. This doesn't fix previously broken exported project exports,
but new exports will work.

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

Splits auto-refreshing of MR widget into 2 requests:

- the one which uses etag-caching and invalidates the fields on change
- the one without caching

The idea is to gradually move all the fields to etag-cached endpoint

Removes the feature flag that controls whether
metrics dashboard urls unfurl the metrics dashboard
charts.

Whenever `PostReceive` is enqueued, `UpdateMergeRequestsWorker`
is enqueued and `MergeRequests::RefreshService` is called, it'll
check if the source branch of each MR asssociated to the push exists
or not via `MergeRequest#source_branch_exists?`. The said method will
call `Repository#branch_exists?` which is cached in `Rails.cache`.

When the cache contains outdated data and the source branch actually
exists, the `MergeRequests#RefreshService` job will close associated
MRs which is not correct.

The fix is to expire the branches cache of the project so we have
updated data during the post receive hook which will help in the
accuracy of the check if we need to close associated MRs or not.

This will help identify Sidekiq jobs that invoke excessive number of
filesystem access.

The timing data is stored in `RequestStore`, but this is only active
within the middleware and is not directly accessible to the Sidekiq
logger. However, it is possible for the middleware to modify the job
hash to pass this data along to the logger.

This number was reporting a negative number because `current_time` was
a monotonic counter, not an absolute time.

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

This reverts merge request !31361

The githost.log name was often confused with GitHost.io. Rename this to
git_json.log to make it clear it's coming from Git and that it's JSON
data.

As decided in https://gitlab.com/gitlab-org/gitlab-ce/issues/53593