Add TestCaseWithParameters to testing_utils

This new subclass of TestCase allows construction of test cases
that multiply themselves to get better coverage for various values
of specified variables.

Implementation is a cross between the well-known TestCaseWithScenarios
and my own TestCaseWithInvariants. It allows the developer to
name variable parameters to a test case and provide all the distinct
values they (as a collection) should take. Using this as the base class
it's easy to construct the more limited TestCaseWithScenarios (I have that
as a separate patch) as well as the special-cased invariants.

The code is heavily documented and seems to work well in causual testing.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
make_job() create Origin that tracks source code location

The make_job() is a small utility function used in several tests.
Sometimes, when a job fails to parse or causes other problems, it
may be difficult to find where it came from.

This patch creates an Origin() object that points at the caller
of make_job() and associates it with the newly created test JobDefinition
instance

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
"[r=brendan-donegan][bug=][author=zkrynicki] automatic merge by tarmac"
Add a simple testing script

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Add support for integration tests

This warrants some explanations. Integration tests won't be running as a
part of normal unit testing, hence the test_*.py patter is not used.
This patch allows integration tests to discover all the checkbox jobs
that should be started by inspecting package data (looking for reference
results).

The actual test just compares the outcome of the job with reference
known-good expected values. Those are stored in the source tree and
are packaged along with everything else. To make discovery painless
and irrelevant of installation path I'm using pkg_resource which matches
python3 packaging evolution and the documented best strategy for accessing
package data.

This works very well but after implementing it and giving it some thought
I cannot help to wonder if we need more than one "set" of reference
answers. (in practice the data directory would get a sub-directory
per each data-set). This could be used to test responses from resource
scripts (so reference data would contain actual resources) and other
generators that don't produce one valid data-set but instead slightly
different data-sets depending on the hardware (or software and hardware)
they run on.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Add plainbox self-test command.

This command discovers, loads and executes all integration tests

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Run integration tests when testing for coverage

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
"[r=brendan-donegan][bug=][author=zkrynicki] automatic merge by tarmac"
scripts/network_reconnect_resume_time - do not fail if resume time cannot
be calculated as this usually just means the driver does not print 
appropriate messages to determine this. (LP: #1065009)
"[r=roadmr][bug=][author=zkrynicki] automatic merge by tarmac"
"[r=roadmr][bug=1065009][author=brendan-donegan] automatic merge by tarmac"