We will introduce #cluster at a later stage.
Also deprecate this method

Previously this behaviour was only available to group
and instance-level clusters, as some project clusters
relied on Kubernetes credentials being passed through
to the runner instead of having their resources managed
by GitLab (which is not available when using JIT). These
clusters have been migrated to unmanaged, so resources
can be created on demand for the remaining managed clusters.

Whenever we are selecting a namespace to use for a
deployment or to query a cluster we want to exclude
Kubernetes namespace records that don't have a token
set as they will not have the required permissions.
However when configuring clusters, we want to
use the original namespace record even if it has no
token, as a namespace has to be unique on a cluster.

There seems to be several examples where service_account_token is blank
even in GitLab.com newly created kubernetes_namespaces . We have not
figured out why they are blank but this should hopefully fix some issues
similar to https://gitlab.com/gitlab-org/gitlab-ce/issues/55362

When this option is enabled, GitLab will create namespaces and service
accounts as usual. When disabled, GitLab wont create any project
specific kubernetes resources

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

JIT resource creation blocks deployments if a user is
self-managing their cluster, as it will fail the build
if unable to create a namespace and service account.

Using a custom namespace and service account was previously
supported for project level clusters, so we should preserve
this functionality.

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27352

Instead of attempting to create or update a Kubernetes
namespace on every deploy, only do so when we know it
doesn't exist yet.

Instead of creating a Kubernetes namespace on every
cluster related to a project, only create one on the
cluster the project is about to be deployed to.

Builds that have deployments require Kubernetes resources
to be created before the build can be deployed. These
resources are no longer created when the cluster is
created, which allows us to only create the resources
required by each specific build.