Add collection_property helper to simplify building property filters

[soxofaan]

While working on #328, I thought of this proof of concept to simplify specifying simple collection property filters.

Usage example:

from openeo import collection_property

cube = con100.load_collection(
    "S2",
    properties=[
        collection_property("eo:cloud_cover") <= 75,
        collection_property("platform") == "Sentinel-2B",
    ]
)

note that properties is now a list (instead of a dictionary),
containing these collection_property operator tricks that are translated to the proper process graphs

[soxofaan]

could also be considered a solution for #246

[m-mohr]

I like that, although could "collection_property" be a bit shorter? :-) prop, field, property, key or so.

Because it is longer than before now:

"eo:cloud_cover": lambda v: v <= 75 # old
collection_property("eo:cloud_cover") <= 75 #proposal
prop("eo:cloud_cover") <= 75 # better?

[soxofaan]

It's indeed longer, but only in number of characters.
It's simpler in terms of symbols or concepts: just a function call and a comparison, while with the existing approach you have to understand how lambda works (which isn't the case for most beginners)

collection_property is indeed a bit long, but making it shorted like prop, field, property or key is risky because the user is expected (or will be tempted) to import it globally (from openeo import thing) and you don't want thing to collide with existing globals. property is for example a python builtin global, field and key are very popular variable names with high chance on collision. prop is too short or cryptic in my opinion.

[soxofaan]

I also expect that users are going to copy-paste from example snippets (or use AI driven code generators in the future 😛 ), so I don't think that the extra typing effort for collection_property is that much of an issue

[m-mohr]

But if they copy/use AI anyway, then you can simply stick with "eo:cloud_cover": lambda v: v <= 75 :-P

Another reason not to use collection_filter: We also have other processes that use the property filtering, which are not related to collections, e.g. filter_labels. So I'd argue property or filter - or if you wanna namespace it openeo_filter - are better choices... :-)

[soxofaan]

property and filter are a no-go as they are builtin functions, you don't want a user to accidentally overwrite these. Namespacing like openeo_filter looks a bit weird compared to the rest of the python API.
value_filter could be an option, because that's what it is: a helper to build a {"from_parameter": "value"} filter process graph.

However, I personally still like the concreteness of something like

load_collection(...
    properties=[
        collection_property("eo:cloud_cover") <= 75,

Another alternative is using the terminology "metadata property" as used in the description of load_collection:

load_collection(...
    properties=[
        metadata_property("eo:cloud_cover") <= 75,

[m-mohr]

I just checked it against and my claim that filter_label also uses this is wrong. In all other "logical expressions" (filter_labels, count, aray_filter) you have direct values to work against and don't need the special handling.

In the schema the subtype is called metadata-filter by the way.

[soxofaan]

We decided to push this forward, still sticking with collection_property so that users can start using this. We'll flag it as an experimental feature to keep the option open for a better name if one pops up

[soxofaan]

(squashed and) merged in 40be725