RRULE evaluation: Ignore BYtime if DTSTART is date-only

[minichma]

According to RFC 5545, when evaluating an RRULE based on a DTSTRT of type DATE (i.e. date-only), any BY[SECOND|MINUTE|HOUR] MUST be ignored. This is implemented by this PR.

The BYSECOND, BYMINUTE and BYHOUR rule parts MUST NOT be specified
when the associated "DTSTART" property has a DATE value type.
These rule parts MUST be ignored in RECUR value that violate the
above requirement(e.g., generated by applications that pre - date
this revision of iCalendar).

This fixes the case DTSTART:20241018, RRULE:FREQ=DAILY;BYMINUTE=1,2,3,4;INTERVAL=2;COUNT=3 of #618.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[axunonb]

Nicely commented,, important fix, tnx

[axunonb]

@minichma Feel free to merge the 2 approved PRs after considering whether the remarks are useful or not.

The only thing I'm pretty much convinced by now is: we need more coverage of use cases from the wild, which results in more effort than code coverage. Thanks for the structured approach you already started.
BTW: Would CI based code coverage integration be useful at this time, and if so: What should be the minimum coverage and code quality benchmark for PRs?

[minichma]

Regarding test cases for this fix I was running this based on #617. I think we should consider merging #617 and introducing our own test files in the same format. This would allow us adding new tests very easily and also to update test cases from the libical project. Then we'd also have specific coverage for this PR.

[minichma]

Would CI based code coverage integration be useful at this time, and if so: What should be the minimum coverage and code quality benchmark for PRs?

I'm pretty sure it would. Most important would be that the overall coverage would increase over time. Imposing high quality figures would only be helpful if we also have a reasonable path to get there.