Use Case: 
Support declaring no application in binding: generate intermediate binding secret only

Reasons:

• Dropping it, as this would require the ServiceBinding resource mutable.
• Dropping it, this could be handle with https://github.com/k8s-service-bindings/spec#binding-secret-generation-strategies

Requirements:

• Will need to provide documentation about a different path to achieve the “same use case” 

By using this functionality, some users treat and use the operator as secret generator only. The spec does not provide any alternative yet, i.e. there is a proposal

https://github.com/k8s-service-bindings/spec/issues/145

to make an extension that can generate secrets using an arbitrary mechanism.

We could definitely consider implementing it when the proposal get merged, but would perhaps avoid dropping it on our API, it might impact some users. This functionality still can work even if service binding becomes immutable.

------------------------------------------------------------------------------------------------------------

Are dependencies identified?

There is a dependency on the PR -> https://github.com/redhat-developer/service-binding-operator/pull/913
The current behaviour of ServiceBinding CR allows us to add and then remove application. After 913 PR is merged, user will not be able to add and then remove application.

Are blockers noted?

No blockers to deliver this issue.

Is design implementable?

• Remove `optional` tag from application (https://github.com/redhat-developer/service-binding-operator/blob/master/api/v1alpha1/servicebinding_types.go#L89)

• Remove `EmptyApplicationReason` -> https://github.com/redhat-developer/service-binding-operator/blob/master/api/v1alpha1/servicebinding_types.go#L39

What is the acceptance criteria?

This acceptance test should be updated:
https://github.com/redhat-developer/service-binding-operator/blob/master/test/acceptance/features/bindAppToService.feature#L302

    @negative
    Scenario: Service Binding without application selector
        Given CustomResourceDefinition backends.stable.example.com is available
        * The Custom Resource is present
            """
            apiVersion: "stable.example.com/v1"
            kind: Backend
            metadata:
                name: backend-demo-empty-app
                annotations:
                    service.binding/host: path={.spec.host}
                    service.binding/username: path={.spec.username}
            spec:
                host: example.common
                username: foo
            """
        When Service Binding is applied
            """
            apiVersion: binding.operators.coreos.com/v1alpha1
            kind: ServiceBinding
            metadata:
                name: binding-request-empty-app
            spec:
                bindAsFiles: false
                services:
                -   group: stable.example.com
                    version: v1
                    kind: Backend
                    name: backend-demo-empty-app
            """
       Then Error message is thrown
       And Service Binding "binding-request-empty-app" is not persistent in the cluster

Is the story estimated?

5