LAG functionality, Subqueries, Comparing with NotAvailable values

[DanielLazarHTDM]

Enhancing query engine by:

1. LAG - Lag is now available in query engine - Each datapoint now contains also previous (lag) value. If there is request to feed some datapoint all subrscibers executing query where is possible to check if previous value is different. Than after all subscribes are notified previous lag value becomes the current one.
2. Subquery - SELECT now can use subqueries (check executor.rs unit tests)
   • WARNING it is working slightly different than standart SQL, where we can SELECT something from subquery where usually FROM keyword is used and than values are selected from subquery. Here if:

     SELECT 
     Vehicle.Speed as notSubquerySpeed,
     (SELECT Vehicle.Speed WHERE Vehicle.Speed <> LAG(Vehicle.Speed))

     We will get value if Vehicle.Speed is valid and there is not new feed of this value:

   • notQuerySpeed: FloatValue(101.0) at 1699598734

And if there is an change of value query is returning:

• notQuerySpeed: FloatValue(102.0) at 1699598936
• Vehicle.Speed: FloatValue(102.0) at 1699598936

4. Equals comparsion now enables left or right to be NotAvailable, because of LAG of course if there is first datapoint change

[argerus]

Thanks for the PR!

I tried it out quickly, and it seems to be working as intended. Awesome!

I'll get back with a more thorough review. But again, thanks, and welcome (as I think this is your first submission here)!

[DanielLazarHTDM]

You are welcome,

Yeah it is my first :) I do have some thoughs about improvent like!

• WHERE condition for result of subquery (just an idea) but it should be about implementing FROM functionality and not sure if it is needed. As far as now I am able to query data how I need them
• Maybe bug. As an alias cannot be used something with dot which is common usage at normal SQL life
• Also once PR is approved we should quickly update QUERY.md

[SebastianSchildt]

Looking good. I think @argerus if this is not breaking "simple" examples SQL Syntax we might merge this, even if it breaks our "never touch sdv API again", as at least the external interface is not changed.

In the mid/short term we should probably discuss whether we move/copy the "SQL-like query" entrypoint over to kuksa.val.v1 (no equivalent there currently), or maybe out in a separate proto/API, as it is a bit "different style" of interacting with databroker than just the plain get/set/subscribe thingies