New test for USB after suspend

[Ara Pulido]

There was some discussion about a corner case issue we found when certifying some systems.

In some cases a USB drive didn't work after suspend if it was plugged before suspend.

We are going to add specific tests for that.

As Daniel explained it in an email:

A usb functional tests
B "please insert usb stick again" <- this is new
C suspend/resume
D check that usb stick didn't die, and ask user to remove it anyway <-
this is new
E usual usb after-suspend insert/functional tests

this would be ideal to model with dependencies:

C can depend on B to ensure correct ordering and we can "hack" B to
always pass (to ensure suspend/resume, which is more important,
doesn't get skipped for dumb reasons). However, B can't depend on A
(as C doesn't depend on A and if B depends on A we'd introduce this
implicit dependency), so we need whitelist ordering for that phase.

Can D depend on C? I think so, if we didn't suspend successfully the
usb-after-suspend tests won't run, so whether we remove the stick or
not is irrelevant (and we have bigger problems if suspend failed).

[Daniel Manrique (roadmr)]

I'll set to triaged, as we know the work to do:

- Write 2 new tests, the first one is essentially just a prompt, the second one is trickier as it needs to validate the USB stick didn't die. Can we get a sample of kernel log data of a "dead-after-suspend" stick?

- "freeze" existing 14.04 coverage by copying the cert and self-test whitelists to client-cert-14.04.whitelist (and self-test).
- insert these 2 new tests in the appropriate whitelist (the non-versioned cert ones) so we start applying them in the future. Essentially, the non-frozen whitelists represent "next release" coverage.