since https://github.com/varnishcache/varnish-cache/pull/3855/files
was merged a long time ago and we never supported 7.2 in a public
release.

based on insights with minimum memory testing, we need even more fine
grained priorities.

The main insight is that new objects get lower priorities than
rewrite-related allocations, but once they exist, their subordinate
requests for segments and metadata get higher priorities.

We now also re-assign the priority of waiting allocations.

DLECHK gets a top priority because it uses small allocations and is
vital for rewrite progress.

When we hit an FCO for which we could not lock the varnish object (oc),
we inserted that FCO at the end of the LRU list, and restarted at the
first. But if that FCO was the only one, we would find ourselves in an
infinite loop.

We now put a marker segment on the LRU for the time we need to let go of
the lru lock and continue at that marker.

The exp thread is also critical. It must not starve, otherwise lru
starves also because of hitting OC_F_DYING objects.

Unfortunately, this brings us above 4K, so we fill up with io structs

This way we have a better chance to call the actual return at a more
suitable time, for example outside a lock.

Ref #53

Fixes #52

Closes #50

The fellow_e00029.vtc canary fell over on Ubuntu 20.04 with kernel 5.15

This fixes two bugs:

The most relavant was that we did not increase buddy->wait_pri if the
new priority was higher, which could lead to all kinds of weird effects,
for example:

- starvation/lock up
- LRU removing all of the cache

because there were requests waiting, but buddy_wait_work() did not see
them.

The second bug is that we also called buddy_wait_work() if there
actually was no change (the critical region could find state ==
IW_SIGNALLED).

Also, for the new assertions, we need to set the proper wait_pri for the
case that the priority is lowered.