When the app loads a mailbox, we try to fetch the 20 first messages. The
server will respond with a client error of HTTP400 when the mailbox
hasn't been cached yet. The client then first attempts an *intial sync*,
followed by re-fetching of the 20 first messages.

So far for the conflict-free sequence of commands. In the priority inbox
we have three virtual mailboxes that all try to get their data at the
same time. For initialized mailboxes the server will give away the 20
first messages for the respective query. For the very first access,
however, the mailboxes battle for the initial sync. Each of the
mailboxes will run into the HTTP400 for the mailbox that isn't cached,
then they will all three try to do the initial sync. One of them wins.
The other ones previous *retried* the intial sync. And that is where
things blew up. The attempted initial sync resulted in a regular sync.
And since the client requested a sync (diff) with no known message IDs,
the server assumed that all messages of the mailbox are "new". Hence
there was a huge server load and response, followed by a frozen browser
that tried to render hundrets or thousands of messages at once,
depending of the inbox size.

With this patch the initial sync doesn't actually attempt to retry when
it detects a locked mailbox. That is becaues it doesn't make much sense.
If the mailbox is locked then because some other process already takes
care of syncing. We don't have to do it ourselves. Instead we should try
to actually fetch the 20 newest messages. If that works then the process
is done.

Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>