There have been some pain points with timestamp_sequence for a while:

1. It only supports microsecond increments, rather than string units (i.e. '5d', '15m')
2. It is a stateful function, with the state incrementing on every touch, rather than only on hasNext calls.
3. The function is driven by long_sequence.

For example:

SELECT timestamp_sequence(  
    '2025-06-13T09:00:00'::timestamp,
    60000000L
  ) AS ts FROM long_sequence(60) 
  ORDER BY ts;

This should return timestamps in minutes, but it actually returns them in two minute increments.

This is because the function is accessed both for the ORDER BY ts clause and in the ts projection.

There are workarounds, for example:

SELECT ('2025-06-13T09:00:00'::timestamp + (x * 6_000_000_0L)) as ts FROM (
  SELECT x - 1 as x FROM long_sequence(61)
)
ORDER BY ts;

Instead, we can now generate timestamps as a pseudo-table, using generate_series(NNL/NNS).

 generate_series(
    '2025-06-13T09:00:00', 
    '2025-06-13T10:00:00', 
    '1m'
  );

In Postgres, the range is inclusive. Therefore, you must use '2025-06-13T10:00:00'::timestamp - 1 to omit the final entry, or just adjust the timestamp directly i.e '2025-06-13T09:59:59' or use dateadd i.e dateadd('u', -1, '2025-06-13T10:00:00').

This PR also includes variants for generating LONG and DOUBLE: generate_series(LL/LLL) and generate_series(DD/DDD). The default increment for the DD and LL cases will be 1 or 1.0.

If the third parameter is negative, the result set will be returned in reverse order:

generate_series(1, 5, -2);

If the start/end values are back to front, they will be automatically swapped for you:

generate_series(1, 5, -2);
generate_series(5, 1, -2);
-- ^ these are equivalent ^

All variants support constants or bind variable constants.

This PR additionally fixed a long-standing bu when using non-keyed sample by fill prev, wherein dirty state would be left behind in SimpleMapValuePeeker. In the FILL(PREV) case, since this was not a constant fill, subsequent calls to the function would return different data.

Also, there was an issue in the same cursor where the first timestamp of the range would be skipped, which is now also fixed. This wasn't caught in testing because assertFactoryCursor would always execute assertTimestamp first, so both of the cursor calls were run with already 'dirtied' state.

Also fixes a dirty state bug in LastValueDoubleWindowFunctionFactory.