Don’t let ItemRepPriorityQueue yield items more than once

[denisdefreyne]

Detailed description

It is possible, though unlikely, for the ItemRepPriorityQueue to yield an item more than once.

This happens when an item rep has a dependency on an item that was previously yielded but could not be compiled due to a dependency it had itself. For example, given items A to E:

• item A depends on item D
• item B depends on item A

The order of yielding should be:

1. item A (regular prio; outcome=failure due to dependency on item D)
2. item D (prioritised; ok)
3. item B (regular prio; outcome=failure due to dependency on item A)
4. item A (prioritised; outcome=ok)
5. item C (regular prio; ok)
6. item E (regular prio; ok)
7. item B (least prio)

Previously, item A would be yielded twice: once in step 4 (when it was prioritised) and once near the end (in step 7 or 8). This is because item A ended up being deprioritised (in step 1) but it wasn’t taken into account that in the mean time, it could have been a dependency of some other item, and thus be compiled before ending up in step 7 or 8.

This is a bit mind-bending to wrap one’s head around, which is why there is a test case for this now.

To do

• Tests
• [~] Documentation
• [~] Feature flags

Future improvements could probably include folding @seen and @completed into one, and making @prio_a a nullable object instead of an array.

Related issues

This is a likely fix for #1631.