Handle servers that return UIDNEXT = 0
Despite RFC 3501 requiring that UIDNEXT values are non-zero integers, some mail servers return values of 0 for selectable mailboxes (e.g. #711 (closed)). This is a problem since the engine currently uses the UID class to represent UIDNEXT, and that rejects values < 1.
Treating such UIDNEXT values as invalid prevents MinimalFolder's remote normalisation from proceeding, making it impossible for the folder to be opened and sync'ed. However allowing 0
as a valid UIDNEXT (and hence UID) value (as just landed for UIDVALIDITY in #1183 (closed)) will potentially cause an invalid UID to be sent to the server (e.g. when fetching/searching a range from the earliest position in a mailbox), for which a strict server may quite reasonably reject. Further, it's not possible to know if a server allows UIDs to be 0 unless we see one from the server, as the UIDNEXT for a folder (although per RFC 3501 § 2.3.1.1 it is not necessarily possible to assume that the first email would be assigned UID 0), or by actual UID of an email from a UID FETCH/SEARCH/etc command.
To avoid sending invalid UIDs to conforming servers, the minimum valid UID needs to stay at 1, which likely means accepting the fact that sometimes, if non-conforming servers do assign UID 0 to messages we might not be able to find them.
To handle the actual UIDNEXT value for non-conforming servers, one possible avenue then is to use a separate data type for UIDNEXT values that behaves the same as the UIDValidity class - i.e. allows 0 as a valid value (probably by simply renaming he UIDValidity to something like "UIDStatus" and using it for both), then extending that to support existing call sites if needed.
Once this is done, the workaround for #711 (closed) should be removed.