Query recur instance without dtstart

[sunkup]

Part of bitfireAT/davx5-ose#1336

---

Currently JtxCollection.queryRecur can't query instances of recurring VTODOs (got RECURRENCE-ID property) which don't include a DTSTART. This is a valid scenario though and so it should be supported by ical4android.

VEVENTs, in contrast to VTODOs, do require DTSTART to be present when there is a RECURRENCE-ID, but they should still be able to be uniquely identified with UID and RECURRENCE-ID alone. I am writing should, because in theory it could happen that two calendars contain events which both have the same UID and since queryRecur does query across all collections, it could happen that we get two VTODOs / VEVENTs back when expecting one only. It seems highly unlikely though.

While using DTSTART as a third query param makes this scenario more unlikely it could still happen and worse: it introduces said problem.

This PR:

• changes the queryRecur method to not include DTSTART
• Adds a simple test
• changes the queryRecur log message to include the correct method name

Further information

In RFC 5545, Section 3.6.2 – To-Do Component:​

"A 'VTODO' calendar component without the 'DTSTART' and 'DUE' (or 'DURATION') properties specifies a to-do that will be associated with each successive calendar date, until it is completed."

From RFC 5545, Section 3.8.4.7 (UID):

"The UID itself MUST be a globally unique identifier."

And:

"This identifier is created by the calendar system that generates an iCalendar object. [...] The generator of the identifier MUST guarantee that the identifier is unique."

In RFC 5546, Section 3.6.1:

"The primary key for referencing a particular iCalendar component is the 'UID' property value."

[ArnyminerZ]

Should @patrickunterwegs also take a look? Or at least be aware

[rfc2822]

Looks good!

Just wanted to note that there could even be multiple entries with the same UID and RECURRENCE-ID, but different SEQUENCE:

Purpose: This property is used in conjunction with the "UID" and "SEQUENCE" properties to identify a specific instance of a recurring "VEVENT", "VTODO", or "VJOURNAL" calendar component.

(I actually found that once in a Webcal.)

However it's another story. Removing the DTSTART from queryRecur seems fine for me. Hope that we didn't overlook something.