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.
Since we cannot scry the key out of jael during load, and the
alternative is defering this logic through the larval core in some way,
we simply include the type for the old acru interface, letting us reuse
the old core to initialize the new one.
Instead of exporting keys so that caller can do this themselves, we
expose arms for signing and authenticating that produce and operate on
just the signature, without mangling it into the message.
By moving this behavior for packets with ames-style headers into lull,
other vanes that want to do protocols in similar style (like the upcoming
%fine vane) can reuse the logic here.
Note that we parameterize the main en- and decoding functions, so that
we may pass in the "is ames" flag and protocol versions as appropriate
to the context.
