Eliminate wrong assumptions about "terminal" nodes

[soxofaan]

The process graph building logic in Python client quite heavily works from assumption about the equivalence

"end node" = "result node" = "save_result"

which works for most use cases, but that's not fully in line with full openEO API.

also see Open-EO/openeo-geopyspark-driver#424 (comment):

Some more insights from Open-EO/openeo-processes#279 and Open-EO/openeo-api#427 about different kinds of terminal nodes in the openEO API

• a process graph can have multiple "end nodes": leaf nodes that are not input to another node
• a process graph must have one "result node": node with "result": True.
  • The result node is actually just important in the the context of a "callback" (in a "parent" process like apply, reduce_dimension, ...) to determine the value that has to be used by the parent process
  • The "result" property has little meaning for "top-level" graphs
• the result node does not have to be an "end node". Result nodes can be input to subsequent nodes
• a "save_result" node neither has to be "end node" or "result node" to be executed

[soxofaan]

some related tickets

• Client: Support for multiple result nodes #391
• execute_batch silently adds save_result even if there is already one #401
• DataCube.save_result returns DataCube instead of (wrapped) true #402
• Eliminate duplication between DataCube, VectorCube, ... #278

[m-mohr]

Just a short note regarding "The "result" property has little meaning for "top-level" graphs": This is only true when submitted for execution. If stored as a UDP, it actually has a meaning as it's the return value of the UDP.