Recurrence rule validation

[maknapp]

For the various EvaluationException instances related to rrule issues, would it make sense to validate rrules before evaluation? Evaluating a Calendar would throw if just one event was invalid. If rrules were validated on creation, it could be ignored before being added to the calendar. Can this be done without breaking serialize/deserialize backwards compatibility?

[axunonb]

On a first glance, RRULE validation before evaluation is appealing: Evaluation failures that stem from invalid recurrence semantics could be handled early.
But should we evaluate leniently or strictly? RULE:FREQ=MONTHLY;BYWEEKNO=15 is invalid as of RFC5545. Should evaluation fail here? Currently we just return no occurrences.

We could introduce an explicit validation step that clients can opt into before adding items to a calendar, like TryValidateRecurrencePattern. Provide constructors/overloads or a ValidationOptions flag so that libraries that need strict RFC compliance can influence validation. This will add complexity.

With optional validation, however, we still need to surface the existing EvaluationExceptions — validation is just a complementary step.

[byteorbix]

I opened this issue on rrule-temporal re strict vs lenient validation. They now added an option for strict validation, while the default is lenient.

[axunonb]

See also #734