Time column predicates are invalidating use of star-tree indices

In some cases, time-column predicates are disqualifying queries from using star-trees, when they would otherwise be used. Specifically, this appears to be the case when using a dynamic timestamp comparison against the now() operator:

`SELECT dimension, SUM(metric) AS totalMetrics FROM myTable WHERE otherDimension='filterValue' AND eventTimestamp >= cast(now() - 172800000 as long) GROUP BY 1 ORDER BY 2 DESC LIMIT 10`

where a query that uses a static value for timestamp comparison will use a star-tree:
`SELECT dimension, SUM(metric) AS totalMetrics FROM myTable WHERE otherDimension='filterValue' AND eventTimestamp >= 1611161288000 GROUP BY 1 ORDER BY 2 DESC LIMIT 10`

Thanks to @mayankshriv, I'll try to put together a PR to address.

Start by reproducing the supplied queries and tracing how dynamic time-column predicates affect star-tree eligibility. Done means the now()-based comparison can use a star-tree when otherwise eligible, with coverage for both dynamic and static timestamp predicates.

Written by the indexing model from the issue text.