Extract acme double to helper

Create ACME challanges for pages domains

* Create order & challange through API
* save them to database
* request challenge validation

We're saving order and challenge as one entity,
that wouldn't be correct if we would order certificates for
several domains simultaneously, but we always order certificate
per domain

Add controller for processing acme challenges redirected from pages

Don't save acme challenge url - we don't use it

Validate acme challenge attributes

Encrypt private_key in acme orders

Resolve "Use GitLab serverless with existing Knative installation"

Closes #58941

See merge request gitlab-org/gitlab-ce!27173

It used to be the case that GitLab created symlinks for each repository
to one copy of the Git hooks, so these ran when required. This changed
to set the hooks dynamically on Gitaly when invoking Git.

The side effect is that we didn't need all these symlinks anymore, which
Gitaly doesn't create anymore either. Now that means that the tests in
GitLab-Rails should test for it either.

Related: https://gitlab.com/gitlab-org/gitaly/issues/1392#note_175619926

Gitlab::HTTP now resolves the hostname only once, verifies the IP is not
blocked, and then uses the same IP to perform the actual request, while
passing the original hostname in the `Host` header and SSL SNI field.

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

Enabling GraphQL batch requests allows for multiple queries
to be sent in 1 request reducing the amount of requests
we send to the server.

Responses come come back in the same order as the queries were
provided.

remove `Clusters::Platforms::Kubernetes#actual_namespace`

Closes #61935

See merge request gitlab-org/gitlab-ce!28391

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).