snapsserts.DeriveSideInfo* cannot deal with snap-revisions with the
same hash but different provenance in the local system assertion
database, this should be an acceptable limitation for a while
the seedwriter code now assumes that the input can be trusted, this is
reasonable
systems.go uses already installed snaps, so it's fine but probably
would still be good to address the TODO in it for efficiency/clarity
as the code in seedwriter DeriveSideInfo is even more clunky now for
this use case, we should be able to find an applicable snap-revision
by other means
snap revision fetching and cross-checking should take provenance into
account and also verify device scope constraints for revision
authority delegation
provenance is taken as a hint from the store, but then matching
assertions must be found and then provenance is double checked
a failure of the latter check is likely a sign of a bug or
error as an attacker that can submit or forge/sign a blob could
as well do one with the expected provenance
provenance goals are tracing and avoiding the risk of polluting
the snap-revision namespace
this leaves alone the DeriveSideInfo* functions mainly used for
asserted local installs, this means they might fail to find a
snap-revision sometimes, they will be updated in a different branch.
This commit replaces the use of "sanity" with more inclusive
naming.
When `sanity` is used in a more general sense either `validity`
or `quick` is used.
