Merge pull request #431 from chrisccoulson/add-initial-stateful-activ…

…ation-api

Add initial stateful activation API.

This adds a new `ActivateContext` API for unlocking and locking
`StorageContainer`s which will eventually track state (activation
attempts, keyslot errors, and how a container was unlocked) across
calls in a way that can be serialized by snap-bootstrap for
consumption by snapd to improve diagnostics.

This initial implementation doesn't yet retain any state, nor does
it perform the primary key cross check or support passphrases or
PINs. These features will follow in subsequent PRs.

Although no state is created yet, there is a placeholder
`ActivateState` type in this PR so that one can be supplied to
`NewActivateContext`. There is also a new `ActivationStatus` type which
will be part of the state associated with a `StorageContainer` - this
has been added in this PR because it's used in the state machine.

A previous PR introduced the `ActivateOption` type with the intention
that `ActivateContext` would pass these to `StorageContainer.Activate`.
However, this PR changes this so that `ActivateContext` processes any
supplied options and passes the processed options to
`StorageContainer.Activate` (using the `ActivateConfigGetter` interface).
This was done in order to split options into those that can be supplied
context wide, and those that are specific to a single call to
`ActivateContext.ActivateContainer`.

The existing `luks2` implementation of `StorageContainerReader` needed a fix
because it always returned the same `Keyslot` instance (which had a
`io.Reader` attached) when making repeated calls to `ReadKeyslot` with the
same name. This meant that a keyslot could only be read once by the
caller. The implementation now always returns a new `Keyslot` with a new
`io.Reader` every time. As a consequence, token information for platform
and recovery keyslots is now cached using the same code path, without
calling `NewLUKS2KeyDataReader` for platform keys. This means that the
`luks2` package is no longer dependent on the `KeyslotID` and `Priority`
methods of `LUKS2KeyDataReader`, so the `luks2.luks2KeyDataReader` interface
that was used for mocking `LUKS2KeyDataReader` is no longer required - the
tests only need a mock `KeyDataReader`.