Simplify setup of Enterprise Search access through Kibana UI

[sebgl]

Starting version 7.14.0, Kibana becomes the default UI for Enterprise Search.
This PR introduces an enterpriseSearchRef in the Kibana CRD, to simplify the Kibana -> Enterprise Search connection configuration.

Sample manifests to try it out:

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: es-test
spec:
  version: 7.14.0
  image: docker.elastic.co/elasticsearch/elasticsearch:7.14.0-SNAPSHOT
  nodeSets:
    - name: default
      count: 1
      config:
        node.store.allow_mmap: false
---
apiVersion: enterprisesearch.k8s.elastic.co/v1beta1
kind: EnterpriseSearch
metadata:
  name: entsearch-test
spec:
  version: 7.14.0
  image: docker.elastic.co/enterprise-search/enterprise-search:7.14.0-SNAPSHOT
  count: 1
  elasticsearchRef:
    name: es-test
---
apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
  name: kibana-test
spec:
  version: 7.14.0
  image: docker.elastic.co/kibana/kibana:7.14.0-SNAPSHOT
  count: 1
  elasticsearchRef:
    name: es-test
  enterpriseSearchRef:
    name: entsearch-test

You can then access Enterprise Search by clicking the "Enterprise Search" button in Kibana UI.

---

Some technical details:

This is the first time we introduce an association between two resources that does not involve creating an Elasticsearch user along the way. Therefore, aside from the "simple" additional Kibana -> Enterprise Search association, this PR refactors the association controller to allow associations with no transitive Elasticsearch resource, and no additional user creation.

A few noticeable changes:

• Each association's AssociationInfo now contains an optional ElasticsearchUserCreation section to embed the Elasticsearch user creation details (nil in the Kibana -> Enterprise Search association).
• The existing association conf annotation remains unmodified, however a special value can be set on the auth secret name to indicate no auth configuration is required: authSecretName: "-" (as opposed to "" which means the value has not been set yet).
• We now explicitly check whether the referenced resource (not always Elasticsearch!) exists at the very beginning of the association reconciliation.
• I refactored the dynamic watches to ensure we always watch the referenced resource (can be done in a generic way), and conditionally watch the es user secret. No need for SetDynamicWatches in the AssociationInfo anymore.

The PR also adds an integration test to cover the Kibana -> Enterprise Search association, and checks whether the Enterprise Search API is correctly available through Kibana.

Remaining to be done:

• Documentation (through another PR)

[sebgl]

I'm assuming here that no secret will ever be named "-". Since this is a value we set with our own secret naming scheme it should be OK.
It's somewhat nice because it doesn't break the existing schema and is quite easy to manipulate in the code.
However it also feels a bit "implicit", we could also modify the assoc conf schema to make things more explicit. WDYT?

[sebgl]

Jenkins test this please

[pebrc]

Looks good! I like the association refactoring beyond adding the required capabilities I think it is an improvement in general.

We now explicitly check whether the referenced resource (not always Elasticsearch!) exists at the very beginning of the association reconciliation. An additional ReferencedResourceExists() function needs to be implemented by each association controller that knows about the referenced object type.

I think you gave up on that idea and found a generic way with k8s.ObjectExists

[pebrc]

LGTM but I think we need to regenerate the API docs.

[sebgl]

Jenkins test this please