Parse start/end/time/step parameters

[felixbarny]

Only parses the parameters, doesn't actually do anything with them, yet.

I'm hoping we can make start/end optional and a consequence of not specifying is that the start() and end() functions return an error.

This seems like a sensible pattern when used within Kibana, for example when creating an ES|QL-based visualization. Kibana is already supplying a filter for the time range outside of the query itself, so having to specify start/end would be redundant. The start/end parameters can still be used within and outside of Kibana but will likely mostly be useful outside of Kibana, and act similar to TRANGE.

We'll need to solve the issue of increasing the time window we load data from. But I see this as a separate issue that we should solve when tackling window functions. This includes handling the complexity of mixing start/end, time filtering using filter (as Kibana does), and TBUCKET/WHERE filtering in the same query.

Examples:

# instant query
PROMQL time `2025-10-31T00:00:00Z` (avg(foo))
# range query with explicit start and end
PROMQL start `2025-10-31T00:00:00Z` end `2025-10-31T01:00:00Z` step 1m (avg(foo))
# range query with implicit time bounds
# doesn't support calling start() or end() functions
PROMQL step 5m (avg(foo))

[elasticsearchmachine]

Pinging @elastic/es-storage-engine (Team:StorageEngine)

[costin]

Left a round of comments

[costin]

This should now fixed - please verify if that's the case on your end as well.

[felixbarny]

Some tests in PromqlLogicalPlanOptimizerTests are still failing (before and after this change). Maybe you meant PromqlVerifierTests? Some are working now but not all.

[costin]

foo is a quoted identifier that is a reference to a field which the parser should translate into an UnresolvedAttribute(foo).
If you want to parse it as a value use define it as a string - "2025..."

[felixbarny]

I'll follow up on that shortly. I'd like to do that in a separate change as it needs changes to the grammar.