Description
The CachingUidProvider does lazy fetch the "highest" uid of all messages stored in the mailbox on first request of the lastUid for a mailbox or if the nextUid is requested. This works well if there were never emails in the mailbox but MAY fail otherwise..
The problem happens if you for example append 2 messages to the mailbox which get the uids 1 and 2 assigned and then expunge the message with uid 2. As long as the server is not restarted everything works well, but if you do so and a new message will get append it will reuse the uid 2 for it as uid 1 is the last known for it. This is strictly disallowed.
See RFC 3501:
A 32-bit value assigned to each message, which when used with the
unique identifier validity value (see below) forms a 64-bit value
that MUST NOT refer to any other message in the mailbox or any
subsequent mailbox with the same name forever. Unique identifiers
are assigned in a strictly ascending fashion in the mailbox; as each
message is added to the mailbox it is assigned a higher UID than the
message(s) which were added previously. Unlike message sequence
numbers, unique identifiers are not necessarily contiguous.
So even if this will hit the performance we need to store the lastUid everytime we do an append to be sure we don't run in any problems