Index rescan/rebuild

When a folder is accessed for the first time within the backend or the first time after the folder is accessed after it was cleaned up from metacache dovecot may log "info" level messages such as:

Info: obox INBOX: Rescanned index in testuser/mailboxes/c92f64f79f0d1ed01e6d5b314f04886c: 0 new mails, 0 mails lost, 100 kept (iter took 0.003 secs + 0 GUID lookups in 0.000 secs)

Similar "warning" level messages are logged when something unexpected happens. It should always be preceded by an error message:

Warning: obox INBOX: Rebuilt index in testuser/mailboxes/c92f64f79f0d1ed01e6d5b314f04886c: 4 new mails, 1 mails lost, 3 kept (iter took 0.033 secs + 4 GUID lookups in 0.075 secs)

Message parts:

• new mails: These mails were found from Cassandra, but not from dovecot.index. They're added to index.
• mails lost: These mails were found from dovecot.index, but not from Cassandra. They're assumed to be expunged, so they're removed from index.
• kept: These mails were found from both dovecot.index and Cassandra. Nothing is done for them.
• assumed temporarily lost: These mails were found from Cassandra, but not from dovecot.index. When sending a HEAD to Scality to find their GUID, Scality returned 404. Dovecot is now assuming that the mails are only temporarily lost in Scality and will come back later (due to some temporary problem like a split brain). Dovecot keeps rescanning the user every 30 mins until the mails are either gone from Cassandra or visible in Scality. If you're seeing these in logs, you should try to get rid of them since they're causing unnecessary Cassandra lookups. One way of doing this is to add delete-dangling-links parameter to obox_fs when running doveadm force resync (see Obox Troubleshooting: Object exists in dict, but not in storage for how to do this).
• unexpectedly lost during resync: These mails were found from Cassandra, but not from dovecot.index. When sending a HEAD to Scality to find their GUID, Scality returned 404. Also the mail no longer existed in Cassandra. This shouldn't happen unless another Dovecot backend was deleting the user's mails at the same time. Can also happen with CDMI when Scality indexes are out of sync and obox_autofix_storage = yes.