Since Rails 5.0 `request.format` is being set depending on the route extension.

In commits pages we pass a ref as a URL parameter.
If the ref is an extension-like, Rails converts it and sets to
`request.format`.

E.g. if the ref is `some_branch.atom`, Rails starts responding with
`atom` format, but it should response with `html` because `.atom` is the
part of ref name, not the format.

This commit explicitly sets `request.format` to `:html` when needed.

Rails5 fix  expected: 0 times with any arguments received: 1 time with arguments: DashboardController

Closes https://gitlab.com/gitlab-org/gitaly/issues/382

With text/calendar as Content-Type, the browser always downloads the
content as a file (even ignoring the Content-Disposition header). We
want to display the content inline when accessed from GitLab, similarly
to the RSS feed.

Since Rails 5 request.format gets set by extension if it's not explicitly
set.
That means artifacts_controller#file no longer works as expected.
This commit explicitly sets request.format for artifacts_controller#file.

Closes #46192

In Rails 4.2 if params[:format] is empty, Rails set it to :html
But since Rails 5.0 the framework now looks for an extension.
E.g. for `blob/master/CHANGELOG.md` in Rails 4 the format would be
`:html`, but in Rails 5 on it'd be `:md`

This commit explicitly sets the `:html` format for all requests unless
`:format` is set by a client e.g. by JS for XHR requests.

The `errors/access_denied` page should not fail to render when no
message is provided.

When accessing something as a sessionless user, we should also display
the terms message if possible.

When a user checks the `accept` checkbox, we will track that
acceptance as usual. That way they don't need to accept again after
they complete the registration.

When an unauthenticated user visits the `/-/users/terms` page, there
is no button to accept, decline or continue. The 'current-user menu'
is also hidden from the top bar.

Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

When filtering issues with a search string in a group, we observed on GitLab.com
that Postgres was using an inefficient query plan, preferring the (global)
trigram indexes on description and title, rather than using a filter on the
restricted set of issues within the group.

Change the callers of the IssuableFinder to use a CTE in this case to fence the
rest of the query from the LIKE filters, so that the optimiser is forced to
perform the filter in the order we prefer.

This will only force the use of a CTE when:

1. The use_cte_for_search params is truthy.
2. We are using Postgres.
3. We have passed the `search` param.

The third item is important - searching issues using the search box does not use
the finder in this way, but contructs a query and appends `full_search` to
that. For some reason, this query does not suffer from the same issue.

Currenly, we only pass this param when filtering issuables (issues or MRs) in a
group context.

We have a number of import errors occurring with 422 errors, and
it's hard to determine why they are happening. This change will
surface the errors in the log lines.

Relates to #47365

We had `item_project_ids` to help make slow queries on the dashboard faster, but
this isn't necessary any more - the queries are plenty fast, and we forbid
searching the dashboard without filters.

There's no need to add a redundant message to the errors if the
model is invalid. This cleans up the message as well for the importer.

Importing a project from GitHub for a project namespace that already exists
would show an unhelpful error, "An error occurred while importing project."
We now add the base message from Projects::CreateService when this fails.

Closes #47365

#close_merge_request_without_source_project -> close_merge_request_if_no_source_project

This allows us to report JSON parse exceptions to clients and ignore
them in sentry.

When we want to show an access denied message to a user, we don't have
to hide the resource's existence.

So in that case we render a 403, this 403 is not handled by nginx on
omnibus installs, making sure the message is visible to the user.

We show a blue flash banner if the user already accepted, and show a
button allowing them to continue to the application.