Fix stuck acquire queues on partial server errors

When a server responds with two InRelease files, but one
is good, and the other indicates a temporary error, we
queued the other indices from the good repository for
downloading and then queued the retry.

The resulting queue ended up with items having fetchAfter=0
before the item with fetchAfter=<something>, causing the
Run() loop to not detect a stuck queue.

Change the order of the queue such that the highest retry-after
items comes first; this ensures that we always see stuck queues.

This of course changes the behavior of retries in that if one
file fails temporarily we block the entire server. This does
seem more beneficial in the common case - if one file fails,
probably all of them fail, and there's no point bombarding
the server with requests for indices from good repositories
until all have failed.

The actual root cause is more that the remaining items are
Enqueued like this:

1. Enqueue jammy/InRelease (delayed)
2. Enqueue jammy-updates/main all Packages

The resulting queue ended up being:

    jammy-updates/main all Packages
    jammy/InRelease (delayed)

But Enqueue() only calls Cycle() when there are no items in
the queue already - after all, any item that is already running
will call Cycle() eventually. Or so was the case until we added
the retry-after handling.

It's unclear why we don't Cycle() all the time when enqueuing
a new item, given that our pipeline might not be filled yet,
and we could send the request to the server while waiting for
data on a running item.

Trying to always Cycle() however led to regressions that still
need investigating. Given that, this solution certainly is the
more easy to reason about one.

LP: #2003851

0 files changed, 0 insertions, 0 deletions