If a desk is suspended/paused/local, then we should exclude it when
bumping in the +on-load, because a suspended/paused/local desk cannot
have a pending commit that would allow it to bump successfully.
This adds support for tombstoned files to clay. It does not include any
way to actually tombstone them; that is left for later.
This allows tombstoning at the level of a file. Precisely, this expands
+blob:clay by adding a %dead case:
+$ blob :: fs blob
$% [%delta p=lobe q=[p=mark q=lobe] r=page] :: delta on q
[%direct p=lobe q=page] :: immediate
[%dead p=lobe ~] :: tombstone
== ::
Thus, we maintain the invariant that every lobe corresponds to a blob,
but now a blob may be an explicit tombstone.
Details:
- This has not been tested at all, except that it compiles and boots.
- This does not have a state adapter from master. The only state change
is the definition of +cach.
- Additionally, out-of-date ships may unexpectedly receive a %dead blob
from a foreign clay which would interfere with their ability to download
that desk. No code changes necessary, but sponsors should avoid
tombstoning files in %base for a while so their children can get the
update.
- A merge will only fail if the tombstoned file conflicts with another
change. Note that as written, merging from a past desk *can* bring a
tombstoned file to the head of a desk. Possibly this shouldn't be
allowed.
This also includes a couple refactors that were made possible by ford
fusion (since everything is synchronous now) but never got done. In
both cases we get to remove a monad, which simplifies the code
considerably.
- refactor +merge's error handling to use !!/mule instead of threading
through errors
- refactor all +read-* functions and related parts of +try-fill-sub to
eagerly convert lobes to cages.
We also add support reading %a/b/c/e/f/r/x from past and foreign desks,
when possible. Apologies that all of these are in one commit, it was
all a single chunk of work.
This is a draft until we have a way to tombstone. I suspect we'll want
to have a mechanism of keeping track of gc roots and trace to remove,
but this PR doesn't suggest any particular strategy.
