Conversion of CWL runner processes

[soxofaan]

Quick ticket triggered from EOEPCA meeting this morning about openeo process(es) to run run CWL workflows.

• Guidelines and processes to run OGC API - Processes / CWL / EOAP #520 (for Process to run EO Application Packages (CWL) #507) introduced processes run_ogcapi and run_ogcapi_externally (proposal state)
• In https://github.com/Open-EO/openeo-geopyspark-driver
  • we went for run_udf with runtime="EOAP-CWL" and CWL workflow itself or URL pointing to CWL workflow passed as udf argument
  • more docs at https://github.com/Open-EO/openeo-geopyspark-driver/blob/master/docs/udf-eoap-cwl.md
• Epic: MVP support for run_cwl in the openEO backend Eurac-Research-Institute-for-EO/openeo-argoworkflows#23 adds new, non-standard run_cwl process

While most of these implementations are still in PoC/experimental phase, it's probably good to share notes to avoid that implementations/approaches diverge too much

[soxofaan]

cc @m-mohr @EmileSonneveld @Yuvraj198920 @rconway

[m-mohr]

What we wrote in #520 still seems to be valid and good.

• I think a generic runner for CWL should go through run_udf as documented there, indeed. That's what both VITO and EURAC have in the background, right? They just expose it differently as process.
• A process that sits on top of a OGC API - Processes is run_ogcapi, which is still valid but is a different usecase.
• Exposing individual CWL as a separate process is also still valid, but then it's hidden to a user that it's a CWL. That may not even need a mention in principle as the way how we implement openEO processes in the background has always been open to be chosen by the implementation.

We should ideally align on a single name for the UDF runtime.

So at this point this may not need a change in the process or API spec, or maybe just a small one to recommend a UDF runtime name