Instead of having a separate "busy" flag and pending scry request state,
we now have a single "busy" unit that, if there is a pending request,
contains details about the pending request. In the ames case, this is
simply %ames. But in the scry case, it contains all the details we need
to cancel the request, timer, or both when needed.
Additionally, we now make sure to always cancel the scry timeout timer
whenever we get a scry response.
Previously, when the scry timeout fired and we retried the request with
ames, we would always start over from the very first request (ie,
fetching the ""manifest"" containing the files we need to download).
This behavior is not correct in the case where we had already received
that initial response, and were now fetching individual files. So here,
if that's the case, we simply call into +work after marking this peer as
having known-broken scry, which will resume work as appropriate.
(The actual bug here that broke the fallback behavior entirely was the
busy flag not getting unset. We now clean it up properly.)
We also move setting of the sad timer into +retry-with-ames, instead of
doing it at each individual callsite. (In fact, one of the callsites was
missing this behavior.)
When +ke-abet-gone gets called, we're going to remove this keen
entirely. +ke-set-wake does a whole song-and-dance and may even set a
new timer. So instead, we simply call +ke-rest, if we have a known
outstanding timer.
Similar to how %x on the empty desk was already treated specially. We
continue supporting %d on non-empty desks, but do add a print marking it
as deprecated.
The previous commit already started treating the 0v0 commit as
equivalent to the 0 aeon (that is, never-real root), so we should give
the 0v0 commit for all 0 aeons.
Instead of scrying for revisions of files at paths in desks, we now scry
for data corresponding to a given lobe. This removes concerns of aeons,
paths, and other such frivolities, and lets us ask for the specific data
we need regardless of where it may live.
How we're supposed to answer permissioning questions around data this
way remains to be seen.
