Meta: important database changes that require a cache reset

[ChristophWurst]

We currently have a few optimizations and changes that are potentially problematic to apply on a production instance because adding columns and indices to large tables is slow and web updates could therefore run into a timeout. This is a meta ticket to track all of those changes so we can do them in one go, to avoid resetting the cache too often.

• New indices Possible indexes #4466
• Primary keys to big int Change column types for mail_messages and mail_recipients primary keys to BIGINT #4664
• Message parse error flag Truncate email addresses that are more than 244 characters long #4708

A prerequisite for the cache reset is that we lose as little data as important.

• Store new flag_important always on IMAP if the server supports it
• Possibly use new tagging feature/table Add tagging to messages #4665 to restore importance and other flags for servers that don't allow arbitrary tags/flags

[ChristophWurst]

#4665 is scheduled for v1.10. I think it might be best to push that out, ensure that data is put into a more reliable spot (IMAP and the tags table) and then in a v1.11 we can do the big changes.

[ChristophWurst]

We found out that junk has three states: not classified, junk and not junk. We should therefore improve our messages table and add a flag_not_junk column for $notjunk. see #4662

[ChristophWurst]

@miaulalala let's revisit this soon because I think the two todo items are actually done :)

[ChristophWurst]

A prerequisite for the cache reset is that we lose as little data as important

@miaulalala we can tick those two items now, can't we?