Make data stream condition logic more flexible

Problem/Motivation

In #3215938: Data stream email notifications → we are implementing notifications as a data_stream_notification config entity that is configured with both condition and delivery plugins. In that issue we will add an initial numeric condition plugin.

This largely solves a limitation in 1.x where only 1 numeric condition could be configured sensor:

A limitation of this system in farmOS 1.x was that only one notification could be configured per sensor, limiting notifications to a single condition (greater than/less than) for only one named value. It's pretty reasonable to want two conditions per named value, eg: high and low temperatures.

While implementing condition plugins, I quickly realized that opening this up to support multiple conditions introduces other complexity: largely the ability to specify if "all" conditions should be met, or if "any" condition should be met. This can also be thought of as an AND or OR of all the configured conditions on a notification. My initial implementation allows an AND/OR configuration at the top level of the notification that will apply to *ALL* conditions.

Here are some simple use cases I've imagined that this logic should support just fine:
- Notify when a value is greater than OR less than a value (eg: notify when a cooler temp is too high, or too low)
- Notify when a the time is during the day AND a value is greater than a value (eg: target greenhouse temp during the day)
- Notify when one of these named values AND the value is greater than a value (eg: if a data stream has multiple named values)

But this doesn't support more complex logic that may be "grouped" or "nested":
- Notify if a value is in this range OR in this range
- Notify if a value is in this range at day, OR this range at night
- etc...

My initial thought was that this could be solved with "condition groups" similar to how Drupal Views filters work. By default there is a single AND group, but it is possible to configure more complex logic.

But later @symbioquine described a different solution that might be a bit simpler to implement, and perhaps more flexible. The idea is to model all of the conditions in a "tree" structure where each condition can depend on subsequent conditions, with either AND or OR logic (or even something more complex if a custom condition plugin wants to add that logic). This is actually already possible (in theory) with the current implementation - since condition plugins can define their own schema, they could define that their configuration could expect definitions of nested conditions. The condition plugin's evaluate method would evaluate the subsequent conditions as necessary to determine a final result.

By simply adding an and and or condition plugin (or just a single implementation that is configurable and/or) that works as described above, this would be possible. There is also some complexity in making the form UI work OK. And limiting it to a sensible depth.

OR

Maybe we add this "nested" capability to all condition plugins, rather than requiring a special plugin for and/or logic? I think there might benefits either way.

Ideally with this "condition tree" approach we could remove the top level AND/OR configuration from the notification config entity, too, so that there would only be a single condition at the root of the tree.

Another thing that comes to mind is that we are currently collecting all of the successful condition "summaries" in an array that can be used by the delivery plugin (eg: in the notification email, it will say *why* the notification was triggered, "Value was greater than 5".) If the logic that makes a notification evaluate to "true" is nested in many levels, it might be hard to collect all of these "summaries". But I imagine it would be useful to allow users to provide their own summary as well - rather than "Time is during the night" and "Value is less than 5" - "The greenhouse exceeded the nightly temperature limit" might be more useful. Not sure!

Steps to reproduce

N/A

Proposed resolution

Some kind of a condition tree?

Remaining tasks

Decide if this would be useful, or if the simple single level AND/OR is good enough.

User interface changes

Possibly significant changes, some way of configuring "nested" conditions.

API changes

Perhaps abstracting this "nested condition" logic to all condition plugins?

Data model changes

Possible changes to the data stream notification config entity.