If the QRESYNC (RFC 7162) extension is being used, a FETCH response to a
STORE or UID STORE command with the UNCHANGEDSINCE query attribute will
return the mod sequence ID of the performed operation. This information
is crucial for building efficient caching clients.
If the `QRESYNC` extension (RFC 7162) is being used, `EXPUNGE` responses
will return the new highest mod sequence for the mailbox after the
expunge operation. Access to this value is quite valuable for caching
clients.
Use a helper function in `parse_many_into` to support parsing into
any container that implements Extend. Refactor Capabilities to use it.
Delete ZeroCopy and associated bits.
Move Flag into it's own module in types.
While IDLE, the server sends unilateral responses to notify the client of
changes to the mailbox as they happen. Instead of always exiting the IDLE
on any change, allow the caller to pass a callback function which receives
the messages and returns an action to either Continue IDLE or Stop and exit.
For clients wishing to use the previous behaviour, a callback_stop convenience
function is provided that terminates the IDLE on any change to the mailbox.
EXPUNGE may return either a series of EXPUNGE responses each with
a single message sequence number, or a VANISHED response with a
sequence set of UIDs. This adds a wrapper enum and some associated
iterators to make it easy to handle these in the client.
Add support for HIGHESTMODSEQ (RFC 4551) and VANISHED (RFC 7162),
which allows users to quickly synchronize to a mailbox by fetching
only changes since the last known highest mod sequence.
notes
* i tried to avoid the term "async", because that term is very
overloaded and we're not using e.g. tokio/async-io here
* i'm a little unhappy having to string the channel through the
parser, because that seems rather a part of the client logic than
parsing. on the other hand it's better than passing the whole
client, so there's that at least.
