As part of larger effort to move all docs
to index files.

Allow multi select project search for Advanced Search.
Ensure single project search is supported for Basic Search.

Changelog: changed
EE: true

This reverts merge request !52018

This change adds the ability to sort search results by Last Updated

Move search tabs to a Vue component and remove all
unused code.

Replaces HAML dropdown with GitLab UI.
Updates naming.

When we do our keyword highlighting
in the global search, we always
highlight with the color black.

With the new Dark Mode this causes
an issue.

This change uses a darkmode variable
that flips the colors correctly.

Before this commit, if there were two issues with the exact same
name, only one of them would appear in the autocomplete suggestions
list (in the search bar). This commit should fix the problem.

https://gitlab.com/gitlab-org/gitlab/-/issues/276758

At present the merge request result page has an old design and we want
it to match the issue design which was recently updated.

It seems the best way to do this was to share code so we've extracted a
shared HAML template for both of these.

This MR improves empty results page messaging for group and project
searches. We display the group/project name to add more context to the
user.

Hide feature flags link if user does not have permissions
Use let_it_be in search bar spec

Whenever a user changes the search scope from the search results tabs,
the search filters will be reset to their default (i.e. ANY) value.

Enable GitHub Flavored Markdown support for issues to the
search autocomplete field. If the user is in the project
dashboard and enters GFM for an issue id, a link to that
issue will show up.

If a user searches for a commit in a project and only finds
one result, redirect the user to that result. This already
exists for basic search and now is enabled for advanced
search. Added a notice explaining the redirect with a
link back to search results.

This adds support for filtering merge requests by the environment name
and deployment times, in addition to the existing support of filtering
merge requests by a deployment ID. This means you can now get merge
requests that match an environment name, deployment ID, or are deployed
before/after a given date and time. These filters can be combined as
well.

Filtering merge requests by deployments data makes it easy to see what
has been deployed, and when. In addition, you can apply all the other
merge requests filters such as a list of labels to filter by.

This new feature is hidden behind the "deployment_filters" feature flag,
which is disabled by default. This feature flag is a global flag. Merge
requests can be retrieved for both projects and groups, making it
difficult to determine what to scope the feature flag to. So we take the
easy way: it's either enabled for all, or disabled for all. For
something as simple as a few additional filters this should not pose any
problems.

See https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/1246 for
more information.

This MR adds the ability to filter search API results by the
confidentiality flag.

This adds a method to bold the search
term on the issues results page.

This implements the same thing we implemented for [issues](
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40669
) and [merge requests](
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/42560
) now for Epics. This required a slightly different approach as the
`EpicsFinder` was not suitable for this purpose. At present it only
supports searching within a single group. And extending it to support
wider use cases would likely lead to performance issues as there is no
equivalent group permissions cache like `project_authorizations` table
to efficiently determine which groups a user can view epics in.

The simpler thing to do here was to just manually check the permissions
for each returned epic. This leaves a very edge case scenarion in which
a user was previously able to see an epic and looked at that epic in
their last 100 viewed epics and then performs a search and now only sees
4 suggestions (instead of the expected 5). This in theory, if the epic
was renamed and the new name contained something important the user
shouldn't see, could lead to the leak of an existence of that name in
the search results. Considering this edge case is so unlikely it seems
safe to not worry too much about it.

We add 2 refactors:

1. Add `attr_reader :user` to RecentItems because this will be used by
`RecentEpics` since the `EpicsFinder` cannot search outside of a single
group like the `IssuesFinder` does so we need to override `#search`
instead
2. Apply the limit=5 in the RecentItems module instead of the
SearchHelper caller. This is necessary for when we implement Epics
search because we'll need to do a permissions check on the limited items
before returning them

This MR removes users_search feature flag, which has been enabled by
default for a long time.

We introduce a new parameter sort by newest and by oldest
for issues and merge_requests

Code searches allow you to choose branch name or tag when searching for
code. Previously the blob search results were linking to the URL with
the SHA of the branch and not the actual branch name being searched.
This works OK in some cases but usually the user expecting to be linked
to `/master/` instead of `/<some-sha>/` and in particular it is
problematic because when you are loading a file in a specific SHA you
cannot click the edit button to edit that file you just loaded.

We fix this by using the param `repository_ref` when present and
defaulting to the `default_branch` when absent.

See more at https://gitlab.com/gitlab-org/gitlab/-/issues/254932

Pass confidential filter through to search when backed
by PostgreSQL or Elasticsearch.

This reverts commit 1c3e5127, reversing
changes made to 6cd74b81.

This fixes https://gitlab.com/gitlab-org/gitlab/-/issues/254840

The `#use_elasticsearch?` method is not defined in FOSS so we cannot
refer to it. As such the easiest way to handle this is to move the logic
into a helper and override in EE.

This adds a method to bold the search
term on the issues results page.

This implements the same behaviour for merge requests that was added
for issues in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40669.

Add filter ability to basic and advanced search
issues scope. Results can be filtered by state
(any, opened, or closed). Default is any.

This adds support for autocompleting issues that were recently viewed by
the current user when they use the search bar. This data is persisted in
Redis sorted sets as this provides the ability to automatically expire
the data for inactive users, keep the data sorted based on most recently
viewed first and easily keep a limited number of items per user expiring
the least recent ones first.

The recent item tracking is partly implemented as a generic solution as
this will quickly be followed up with merge requests and perhaps other
features people wish to quickly navigate to. The full generic
refactoring will happen when we implement the 2nd usage but for now the
most important thing is to include the data type in the Redis key so
that we don't need to migrate data when we make this generic later.

This feature is behind a feature flag per user for now so we can track
the performance implications in production.

Closes https://gitlab.com/gitlab-org/gitlab/-/issues/208805

See merge request https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26740