The custom Knative function as it's implemented today is highly coupled with the discovery engine.

Ideally, the discovery engine could be performed by a third party instead. This way, when the application is running using an operator, the discovery portion can be delegated to its control.

With this in place, we avoid any Kubernetes client API dependency (infrastructure code) in the runtimes core. So that the Knative/Kubernetes add-ons can just focus on the request and querying the internal catalog.

From the Runtimes' perspective, the sequencing should be:

1. If discovery is present, query the Kubernetes API for the endpoints
2. Populate the inner service catalog (resource GVK as the ID, URI as the value)
3. Fetch the catalog
4. Make the request

From the Operator's perspective:

1. Parse the Workflow CR
2. Discover every Knative/Kubernetes object in the function definitions
3. Populate the internal catalog
4. Start the application. The application then starts its flow as seen in the Runtimes' flow.

The internal catalog can be a simple in-memory key/value or persisted in the file system. For a first iteration, it could be only in-memory, not shared amongst other workflows within the same namespace.

This catalog should be open for writing externally by secured actors. Can be either a YAML, JSON, or any structured file, an internal endpoint, a property, or environment variables. We should be able to answer these implementation questions in this JIRA.

To make it clear: The runtimes won't enable discovery when managed by the operator. This feature MUST be delegated to the operator. The Quarkus Kubernetes Client extension SHOULD NOT be included in the builder/runtime image.

The deliverable is expected to be an implementation document and JIRAs based on the agreed implementation amongst the parts involved.