Do not ignore errors when updating quota or resyncing UIDs

[link2xt]

This is an attempt to debug #6477. It looks like at least once IMAP loop got stuck after updating quota timed out without logging anything.

First commit adds some logging and makes update_recent_quota bubble up the errors. Next commits turn errors from update_recent_quota and resync_folders into loop failure.

It is dangerous to ignore network errors during IMAP loop because if there is a timeout during reading, it does not mean that the next read will not succeed and return leftover or later received bytes. This is how tokio-io-timeout works and this is consistent with how normal TCP connections and C sockets work - timeout errors does not mean the socket will return the same error on the next call. I still don't know however why this can result into the loop getting stuck, I/O should timeout eventually, so there is likely some parser error involved anyway, but not feeding leftover bytes into it makes it more difficult to trigger at least.

[link2xt]

Another parallel PR to make it less dangerous even if the error is ignored and the stream is not dropped after the first error:
#7014

[Hocuri]

So, does this mean that if a provider erreneously says that it has the quota capability, while it actually does not, connecting to this provider will fail?

Not sure whether this ever happens, but also, not sure whether we should include this right before the release - otoh, it hopefully also fixes a bug.

[iequidoo]

Before, quota.modified was updated in this case, maybe still do so and then bubble up the error? This way we won't try to update the quota again after reconnecting. This would be closer to the previous behavior

[link2xt]

Let's merge it as is after 2.x releases and see if anyone reports problems. I will try to finish #7014 instead, it should prevent stream reuse after error while still allowing to ignore errors here.