Fix overzealous IDLE handling
Fix overzealous IDLE handling

We were sometimes entering the IDLE state even during a multi-part message
fetch, between one part and the other. This happened because we call
imapx_command_start_next() which sees an empty queue and triggers IDLE,
before we called the completion handler for the previous command which
puts a new FETCH request into the queue.

Similar behaviour was seen in various other situations, including between
subsequent sync_message() calls from the front end.

Fix this by having a dwell time of 2 seconds between the queue becoming
empty and actually sending the IDLE command. Only if the queue _remains_
empty for 2 seconds do we really enter the IDLE state.

Clean up the IDLE handling to use a state machine instead of a set of
boolean flags, while we're at it.

tintou/evolution-data-server,tintou/evolution-data-server,matzipan/evolution-data-server,Distrotech/evolution-data-server,tintou/evolution-data-server,matzipan/evolution-data-server,gcampax/evolution-data-server,matzipan/evolution-data-server,matzipan/evolution-data-server,Distrotech/evolution-data-server,gcampax/evolution-data-server,tintou/evolution-data-server,Distrotech/evolution-data-server,matzipan/evolution-data-server,Distrotech/evolution-data-server,gcampax/evolution-data-server,Distrotech/evolution-data-server,gcampax/evolution-data-server