Adding label selectors for services

[arthurdm]

This issue proposes a new approach (different than #184 and #179) where you would be able to use label selectors for services in the ServiceBinding CR itself.

Here's an illustration of the desired outcome:

apiVersion: service.binding/v1alpha2
kind: ServiceBinding
metadata:
  name: my-binding
spec:
  service:
    apiVersion: com.example/v1
    kind: Database
    selector:
      matchingLabels:
        app: my-db
  workload:
    apiVersion: apps/v1
    kind: Deployment
    name: online-banking

The behaviour from the controller is such that:

• this can match 0..* services
• for each label match we mount the provisioned service as if it was a named match, with the only difference being that we attach the suffix of -x to the mounting directory name, e.g. my-binding-0, incrementing by 1 for each match
• the lifecycle of these matches follow the exact same semantics as we have for workloads today in terms of new matches coming in, existing matches being removed, etc, as well as how the partial status are reported. This is the current snippet from the spec which would equally apply to services:

  As label selectors are inherently queries that return zero-to-many resources, it is RECOMMENDED that ServiceBinding authors use a combination of labels that yield a single resource, but implementors MUST handle each matching resource as if it was specified by name in a distinct ServiceBinding resource. Partial failures MUST be aggregated and reported on the binding status's Ready condition.
  

• environment variables is the tricky part to define if the values are different. Needs some design on this.
  • one idea can be to disallow environment variables if a service label selector is used. The information is always available in the mounted directory, so there's a way to reach it and create env vars from it if desired.

[arthurdm]

btw - this is for after our 1.0 GA.

[baijum]

• one idea can be to disallow environment variables if a service label selector is used.

I would prefer this approach to disable environment variables to avoid any name conflict. This is important for the proposal that I created in the issue #136 (comment).