to have the information available when we seal capture classic in
modeenv and bootchains as we do for other mode characteristics
as for now we assume we don't want so support classic/core remodels
some things need to be tested but it's best if the tests are added
when we are actually looking at the full picture of installing classic
systems with modes
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.
