2a1b4917

Author: Tom Sydney Kerckhove <syd@cs-syd.eu>

Committer: Tom Sydney Kerckhove <NorfairKing@users.noreply.github.com>

ical-recurrence: test that the limit only ever reveals more occurrences

The limit is an implementation detail of this library, not anything a
recurrence rule says, so raising it must only ever reveal occurrences
beyond the old one.  It must never change the occurrences already below
it.  This is the general form of the BYSETPOS bugs: monthly, weekly and
yearly each had a limit narrowing a candidate set that a rule part then
selected from, so raising the limit moved the instance BYSETPOS picked.

This passes, so there is nothing red here and no accompanying change; it
is a guard against that whole class coming back rather than a fix.

It is a guard that works.  Reintroducing just the monthly leak, the one
line `guard (d <= limit)` back inside the list filterSetPos numbers, and
running this alone fails at case 35 on a generated FREQ=MONTHLY rule with
BYSETPOS.  It was checked that way rather than assumed to be load
bearing.

SECONDLY, MINUTELY and HOURLY are excluded.  The limit has day
granularity, so the narrowest window this can ask for still spans 86400
seconds, and generating that many occurrences twice per case is too slow
to be worth it.  They step through the same code as the rest.

Verified out of band to 1000 cases.  It runs at the default 100 in CI,
because 3000 takes longer than sydtest's per-test timeout.

Timeline