Process iMip responses

[miaulalala]

Is your feature request related to a problem? Please describe.

See #160

Describe the solution you'd like

Backend:

• Provide backend parsing for body parts with content type "text/calendar" in getBodyStructureData (REPLY, CANCEL)
• Create database columns on oc_mail_messages that tells a BG job that there is a caldav response to process (REPLY, CANCEL) and one that is set to true if the scheduling has been processed already
• refactor mail processing to also be done when syncing and not only on loading the envelope list
• Create BG job that allow processing of reply and cancel emails
• In this BG job, access the pulic calendar API and get all calendars - search via UID for the event
• Check all security implications such as the recipient being the ORGANIZER etc as specified in the RFC and the write to the calendar

[miaulalala]

Comment from my PR:

The way we currently only load envelope data means we can never really process all messages as we don't know whether they contain an iMIP body part.

Suggestion 1: only process messages that are opened (where the loading of the body data means we would update the is_imip_field in the db and later pick it up in the background job)

Benefits: efficient, no overhead
Drawbacks: we can never be sure we have processed all iMIP messages in the mailboxes and might miss important ones. Since the processing itself is done hidden in a background job it could confuse users as to why certain messages were processed and others weren't.

Suggestion 2: get all new messages in a mailbox and additionallyload their body content too in a background job (whether we extend an exisiting job or add a new one could be debatable - I would tend towards option 1).

Benefit: we would definitely catch all messages
Drawback: loading data from IMAP is slow and could hit us straight into the performance.

I would prefer option 2.

For the preformance issue I propose the following solution (thanks to @st3iny who helped me on this):

We could extend the horde cache and implement our own horde cache class that lets us cache body content, or we could use ICache. It is more work but it would enable us to cache IMAP messages making Mail a lot faster. Since IMAP messages are immutable, we could cache them indefinitely or until they are deleted - or we could set a cache limit of a couple of weeks or even a month, it would still help us.

I would not cache message bodies in the database.

It would also help with full text search for mail, etc...

An input from @kevincox was that we should also process messages that are being opened immediately as to not lose their content when they are deleted. There th background processing would miss the message.

[miaulalala]

Another point to think of: how do we handle the state of what we replied in a REQEST type iMIP method?

We have 3 options plus guests & comment.

We should ideally remember the state we submitted and possibly how many guests and comments.

Currently, we have no way to store that in the db. we could add a table that stores the sent ICS. or we could treat the ICS as an additional attachment and store that in the appdata folder to parse back from. Or we could read from calendar.

[ChristophWurst]

#6812 is not done.