Adds the backend boilerplate for ModelsController#index

Changelog: added

Moves fetching code to CandidateFinder and adds a search box
to ml_experiments.vue component, reusing RegistrySearch
component. Using GlFilteredSearch is a bit of overkill here
since we are not using Filters, but this is planned to come
soon

Changelog: added
FeatureFlag: ml_experiment_tracking

Changelog: added

See https://gitlab.com/gitlab-org/gitlab/-/issues/353901

Changelog: removed

This will make the fix generally available for owners of personal
projects to have OWNER access level membership.

Changelog: changed

Changelog: changed

Owners of personal projects are displayed as maintainers in the members
page. This change fixes inconsistency for new projects. It is behind
the personal_project_owner_with_owner_access feature flag.

This reverts commit 63974e4d, reversing
changes made to ab524a54.

Changelog: fixed
Signed-off-by: Rémy Coutable <remy@rymai.me>

Owners of personal projects are displayed as maintainers in the members
page. This change fixes inconsistency for new projects. It is behind
the personal_project_owner_with_owner_access feature flag.

This MR makes changes such that we now use
`Arel::Nodes::ValuesList` in
`EffectiveAccessLevelFinder` to generate
the query that finds members with
their user ids and access levels
in a given project.

Changelog: added

This change removes the check on the value of
`lock_memberships_to_ldap ` setting
that was previously being done while refreshing
authorizations via the `EffectiveAccessLevelFinder`
finder.

Changelog: fixed

This change adds a service class to
recalculate project authorizations
of a project per user.

We are removing one-click applications from GitLab but leaving the
integrations for Prometheus and Elastic Stack.

We have code in place that keeps the integration in sync with the
corresponding cluster application, and have backfilled the
ingtegrations, so we can now use them as a source of truth.

See

- Backfill Prometheus: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61502
- Backfill Elastic Stack: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61521
- Deprecation Epic: https://gitlab.com/groups/gitlab-org/-/epics/4280

Contributes to https://gitlab.com/gitlab-org/gitlab/-/issues/28902

* Filter out shared groups user does not have access to

Changelog: added

Contributes to https://gitlab.com/gitlab-org/gitlab/-/issues/28902

* Add `ProjectGroupFinder` to fetch ancestor and shared groups for the
project
* Add `projects/:id/groups` endpoint to Project API
* Add documentation for the new endpoint

by not exposing any detailed information,
which might be a security issue

Check that Jira issues integration feature is available for the
projeect in its current plan tire.

Allow filtering of jira issues by status, labels, author and assignee

for jira issue controller

that will get supplied by the frontend

for use in JqlBuilderService

Adding a service for quring Jira REST API and fetching issues to
be presented for jira issues integration.

It uses a specific worker/queue to process the work that
require external services. That's because this kind of
work should not be mixed with other time-sensitive work.

Currently, lock files are used to determine the state of a
project export. However, the lock files are not stored in a shared
volume, causing the export states to be reported incorrectly.

In order to fix this, we now store the export states in database
as a more reliable mechanism. The table used is project_export_jobs.
It stores the project_id, job_id and the current state.

In addition to existing states, also added are two new states
queued and regeneration_in_progress states. They are used to indicate
a job that's waiting to be started and the case when a project export
operation has been requested to be re-generated.

Failed jobs are re-tried 3 times, after which the state is updated
to failed.

To account for jobs that get stuck, a cron job runs every hour
to set the stuck jobs to failed state.

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

When cluster on which the function runs has serverless domain

Moves `Alert` and its dependencies to CE:

* Alert
* Alert factory
* Alerting::AlertAnnotation
* Prometheus::AlertPresenter
* Prometheus::AlertFinder

When no deployment has been done yet, there is no environment, so the
check for Knative needs to happen via Kubeclient

Kubernetes deployments on new clusters will now have
a separate namespace per project environment, instead
of sharing a single namespace for the project.

Behaviour of existing clusters is unchanged.

All new functionality is controlled by the
:kubernetes_namespace_per_environment feature flag,
which is safe to enable/disable at any time.

Remove Kn services cache from Clusters::Application::Knative

Knative function can exist even if user did not installed Knative via
GitLab managed apps.

-> Move responsibility of finding services into the Cluster
-> Responsability is inside Clusters::Cluster::KnativeServiceFinder
-> Projects::Serverless::FunctionsFinder now calls depends solely on a
cluster to find the Kn services.
-> Detect Knative by resource presence instead of service presence
-> Mock knative_installed response temporarily for frontend to develop

Display loader while `installed === 'checking'`

Added frontend work to determine if Knative is installed

Memoize with_reactive_cache(*args, &block) to avoid race conditions

When calling with_reactive_cache more than once, it's possible that the
second call will already have the value populated. Therefore, in cases
where we need the sequential calls to have consistent results, we'd fall
under a race condition.

Check knative installation via Knative resource presence

Only load pods if Knative is discovered

Always return a response in FunctionsController#index

- Always indicate if Knative is installed, not installed or checking
- Always indicate the partial response for functions. Final response is
guaranteed when knative_installed is either true | false.

Adds specs for Clusters::Cluster#knative_services_finder

Fix method name when calling on specs

Add an explicit check for functions

Added an explicit check to see if there are any functions available

Fix Serverless feature spec

- we don't find knative installation via database anymore,
rather via Knative resource

Display error message for request timeouts

Display an error message if the request times out

Adds feature specs for when functions exist

Remove a test purposed hardcoded flag

Add ability to partially load functions

Added the ability to partially load functions on the frontend

Add frontend unit tests

Added tests for the new frontend additions

Generate new translations

Generated new frontend translations

Address review comments

Cleaned up the frontend unit test.
Added computed prop for `isInstalled`.

Move string to constant

Simplify nil to array conversion

Put knative_installed states in a frozen hash for better read

Pluralize list of Knative states

Quey services and pods filtering name

This way we don't need to filter the namespace in memory.
Also, the data we get from the network is much smaller.

Simplify cache_key and fix bug

- Simplifies the cache_key by removing namespace duplicate
- Fixes a bug with reactive_cache memoization

Clusters::Cluster::KnativeServicesFinder becomes
Clusters::KnativeServicesFinder

This is to avoid loading race condition between:

```
module Clusters
  class Cluster < ApplicationRecord
```

and

```
module Clusters
  class Cluster
```

Remove Kn services cache from Clusters::Application::Knative

Knative function can exist even if user did not installed Knative via
GitLab managed apps.

-> Move responsibility of finding services into the Cluster
-> Responsability is inside Clusters::Cluster::KnativeServiceFinder
-> Projects::Serverless::FunctionsFinder now calls depends solely on a
cluster to find the Kn services.
-> Detect Knative by resource presence instead of service presence
-> Mock knative_installed response temporarily for frontend to develop

Display loader while `installed === 'checking'`

Added frontend work to determine if Knative is installed

Memoize with_reactive_cache(*args, &block) to avoid race conditions

When calling with_reactive_cache more than once, it's possible that the
second call will already have the value populated. Therefore, in cases
where we need the sequential calls to have consistent results, we'd fall
under a race condition.

Check knative installation via Knative resource presence

Only load pods if Knative is discovered

Always return a response in FunctionsController#index

- Always indicate if Knative is installed, not installed or checking
- Always indicate the partial response for functions. Final response is
guaranteed when knative_installed is either true | false.

Adds specs for Clusters::Cluster#knative_services_finder

Fix method name when calling on specs

Add an explicit check for functions

Added an explicit check to see if there are any functions available

Fix Serverless feature spec

- we don't find knative installation via database anymore,
rather via Knative resource

Display error message for request timeouts

Display an error message if the request times out

Adds feature specs for when functions exist

Remove a test purposed hardcoded flag

Add ability to partially load functions

Added the ability to partially load functions on the frontend

Add frontend unit tests

Added tests for the new frontend additions

Generate new translations

Generated new frontend translations

Address review comments

Cleaned up the frontend unit test.
Added computed prop for `isInstalled`.

Move string to constant

Simplify nil to array conversion

Put knative_installed states in a frozen hash for better read

Pluralize list of Knative states

Quey services and pods filtering name

This way we don't need to filter the namespace in memory.
Also, the data we get from the network is much smaller.

Simplify cache_key and fix bug

- Simplifies the cache_key by removing namespace duplicate
- Fixes a bug with reactive_cache memoization

When Kubernetes clusters were originally built they could only
exist at the project level, and so there was logic included
that assumed there would only ever be a single Kubernetes
namespace per cluster. We now support clusters at the group
and instance level, which allows multiple namespaces.

This change consolidates various project-specific fallbacks to
generate namespaces, and hands all responsibility to the
Clusters::KubernetesNamespace model. There is now no concept of
a single namespace for a Clusters::Platforms::Kubernetes; to
retrieve a namespace a project must now be supplied in all cases.

This simplifies upcoming work to use a separate Kubernetes
namespace per project environment (instead of a namespace
per project).

When Kubernetes clusters were originally built they could only
exist at the project level, and so there was logic included
that assumed there would only ever be a single Kubernetes
namespace per cluster. We now support clusters at the group
and instance level, which allows multiple namespaces.

This change consolidates various project-specific fallbacks to
generate namespaces, and hands all responsibility to the
Clusters::KubernetesNamespace model. There is now no concept of
a single namespace for a Clusters::Platforms::Kubernetes; to
retrieve a namespace a project must now be supplied in all cases.

This simplifies upcoming work to use a separate Kubernetes
namespace per project environment (instead of a namespace
per project).