Don't set created and last modified fields when not present in ICS data.

CREATED and LAST-MODIFIED fields are not mandatory in RFC5545. Unfortunately, Incidence::recreate() is unconditionally setting a created and a last modified time stamps. This causes all read events or todos from ICS data to always have a created date and a last modified one.

It was a pending MR I forgot during the migration from phabricator, see https://phabricator.kde.org/D26662

I'm putting here again the comment I originally wrote there:

The patch is not necessary the ideal one, but I would like to start a discussion on this matter. Currently, when calling ICalFormat::fromString(), all created incidences feature a created() and a lastModified() properties. They either come from the values read from the ICS data string, or they are set to the current date time by Incidence::recreate() from Incidence constructor.

RFC 5545 is specifying that CREATED and LAST-MODIFIED fields are not mandatory. With the incidence creator setting these two unconditionally, we cannot distinguish between ICS data with or without created and last modified fields set.

I wonder if we should on the contrary to the current patch, change Incidence::Incidence() itself, not to call Incidence::recreate() but just set the revision to 0 and set the scheduling id, but not set created and last modified. This would be more matching the RFC, but it is a huge change that could have unexpected consequences, since code may rely on the fact that the constructor of Incidence do set these two fields.

Finally, the patch itself may indeed suffer from the same unexpected consequences.

What do you think ? Should we ignore this, try to get incidence closer to the ICS data, or even don't set created and last modified field by default ?