This can occur after upgrade, or when receiving a %delta blob. We do not
know the path or commit timestamp of a file that resolves to the blob,
so we simply fall back to old ames-style blob-by-lobe fetching.
In +work, we simply want to fetch file data, regardless of what the
overarching request is. (In fact, %sing would likely never hit this path
anyway.)
In order to be able to make the scry request, we track the timestamp of
the commit that contains a blob we're missing, and scry for that %da
revision.
There's two edge cases where we cannot immediately know the timestamp
that are currently assumed broken. Fix soon.
%v requests are already handled specially for the ames case. We should
continue to respect that, only doing those kinds of requests over ames.
Also cancels the scry timer after receiving a response, instead of not
doing that.
Ancient version upgraders beware! If you're coming from a home-based
arvo, you must first upgrade to the version prior to this, or else
you'll be in trouble!
When clay wants to download blobs from a foreign ship, it attempts doing
this using the new remote scry protocol.
If it doesn't receive a response within ~m1, it falls back to using the
old ames-based syncing instead. We remember this "prefer ames" state for
the specific ship for an hour, after which we'll begin trying the scry
flow again.
Compiles, but untested. Some TODOs and REVIEWs remaining herein.
We intentionally leave the dist-upgraded flag in state to avoid
cluttering the diff here. The next commit will remove it.
When you loaded an app with an error, then fixed the error, it would
create the main gall %mult subscription at a time in the past. Then,
clay would never fill the subscription since it couldn't get the old %a
entries for the apps.
This fixes the issue in two ways: first, don't subscribe in the past.
Second, if clay can't get the old versions, just fire the subscription
anyway.
