Currently, setting a repo to trusted can result in data loss if content
gets removed from that repo. For this reason, --trust has been disabled,
and `git-annex trust` needs --force.

My idea for a better way to handle this is to make trusted repos that
cannot be checked not count toward satisfying mincopies. So while trusting
a repository would let numcopies be violated still, it would avoid data
loss. That would be enough to bring back --trust and not need --force.

Aside from preventing data loss in some situations, the impact of this
behavior change would be that dropping content would fail in some
situations where it used to work. Specifically, when a trusted repo
contains content, but is not accessible, and no other accessible repo
contains the content. That has been a valid use of trusted repos, but it's
also obviously an unsafe one -- if that trusted repo has dropped the
content in the meantime, it risks data loss.

So, is it worth breaking an existing, but unsafe use case, in order to make
it easier to use trust safely?

Without an answer to that question, one approach would be to add an
ultimatelytrusted level, which behaves like trusted does now. The
serialization of ultimatelytrusted would be what is used for trusted now,
so existing trusted repositories would convert to it, and no behavior would
change. The new trusted would use a different serialization, which old
versions of git-annex would be unable to parse, but parsing defaults to
semitrusted, so old versions of git-annex would behave safely.

Then after some amount of time, users can be polled to see if they
need ultimatelytrusted, and if not it can be deprecated and eventually be
changed to be the same as new trusted. Or, a gitconfig can be added that
makes ultimatelytrusted behave the same as trusted.

That seems like a reasonable plan.

(I thought about just adding a gitconfig now to control which behavior
to use for trusted, but that would not be safe, if a user expects the new
trusted behavior, they could `git-annex trust` a repo, but then later
the gitconfig gets unset, or is not set in a clone.)

----

A complication with implementation: Currently when checking if a drop is safe,
trusted repositories result in a TrustedCopy, and are not checked. And it
checks other repositories until it has enough other evidence that the drop
is safe. But now it would need to check some trusted repositories,
while providing TrustedCopy for ones that it has not checked.

One way to deal with that is, check trusted repositories in amoung the
rest (in cost order). If content is present, add a LockedCopy or
a RecentlyVerifiedCopy to the evidence. If the content is not present,
add nothing to the evidence (or could add TrustedCopy, but there seems 
no benefit to doing that). If the repository cannot be accessed, add
a TrustedCopy to the evidence.

--[[Joey]]
