During VerifyStart we may return early if there are no enrolled prints.
In such case we don't require the verification to be stopped if we're
using identification, but in the verification case we may leave the
device into the verification state.
So ensure we only set the device current state only when we're about to
start it.
Add tests ensuring those cases
The user may have some invalid prints saved (like the ones enrolled with
fprintd 1) in the storage, this lead to list such prints as enrolled but
they're actually not valid.
So load the prints to ensure that those are of the valid type instead of
just discovering them.
We may make just store.discover_prints to be aware of this, but this
would break some assumptions we do in tests, so better to go this way.
We may want to be able to load the user prints to check whether they
are usable, so add an utility function for this.
And use it also in load_all_prints().
It might make sense to push this into the storage layer. But, overall,
it is OK to live here, and if we do make changes on the storage layer we
probably want to change more than just this.
If something under the hood failed with a generic device error we'd just
mark the PAM module not available, this is probably too much as it may
just be due to a device temporary error.
So make it stop but allow the loading system to retry with it
Loading saved prints may lead to an error if they were stored long time
ago and so they're using a wrong format.
In such case we list the prints as available even though they are really
not, so the PAM module won't return PAM_AUTHINFO_UNAVAIL as in the
no-prints case but PAM_USER_UNKNOWN.
This will lead some auth systems (such as gdm) to keep retrying using
PAM fprintd module, even if it's not really available.
When saving the prints we use g_file_set_contents under the hood and in
case return its error code that is a positive value.
So in such case we don't fail if we have a write failure at the end of
the enrollment.
While we could ensure in file storage to always return a negative value,
it's always better to ensure that is has to be 0 when we didn't get an
error.
Add a test checking for this case.
Since we so far we had no duplicated-check for prints in fprintd an user
may have enrolled the same print for multiple accounts or even for
different fingers, so we need to simulate this case.
Given that fprintd may not allow to enroll duplicated prints soon, it's
better to just copy the storage value so that we simulate a duplicated
enrollment in the past.
Allow to enroll multiple data in a single shot so that we don't have to
do it for each user, and add a test that uses it to match each possible
combination.
Some tests were delaying VerifyStop by not reporting the finger status
in the image driver, we can do the same using sleeps in the virtual
device driver, so let's reimplement such calls
