Sequence iterator does not resolve reverse order ranges

[superboum]

Observation

Given the following sequence set: 22,21,22,*:20 and a last message with id=23. I expect to get: 20, 21, 22, 23 (in any order) I am currently getting: 22, 21, 22 (23 and 20 are missing as the reverse order range is skipped, no deduplication is performed and thus 22 appears twice)

Remarks

• [x] ❌ When sequences are in reverse order, they are skipped instead of being resolved. It's not compliant with RFC3501
• [x] ℹ️ The identifiers might de-duplicated but it's not mandatory. It could be the subject of an optimized/specific iterator.
• [x] ℹ️ The identifiers might be sorted but it's not mandatory. It could be the subject of an optimized/specific iterator.
• [x] ℹ️ The resolve logic is not intuitive, giving an example in the documentation showing all the ways the iterator can breaks the "least astonishment principle" would greatly help ^^

(Feel free to close this issue as long as the reverse order range is fixed, the other parts are for informational purpose only).

References

Relevant to reverse order ranges:

Example: 2:4 and 4:2 are equivalent and indicate values 2, 3, and 4.

From IMAP4rev1

Relevant to de-duplication and re-ordering:

Set of seq-number values, regardless of order. Servers MAY coalesce overlaps and/or execute the sequence in any order. Example: a message sequence number set of 2,4:7,9,12:* for a mailbox with 15 messages is equivalent to 2,4,5,6,7,9,12,13,14,15

Example: a message sequence number set of *:4,5:7 for a mailbox with 10 messages is equivalent to 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and overlap coalesced to be 4,5,6,7,8,9,10.

From IMAP4rev2

[duesee]

I converted your list to items. All resolved by https://github.com/duesee/imap-codec/pull/416 :-)