Splits the SDK test implementation into configurable Python classes. The
classes used for the normal and extensible SDKs are
${TESTSDK_CLASS_NAME} and ${TESTSDKEXT_CLASS_NAME} respectively.

This allows SDK machines to override the classes used to implement the
tests. For the traditional SDK, a common "run()" function is provided by
the class (oeqa.sdk.testsdk.TestSDK), with several hook member functions
that can be overridden in child classes, making it easier to have
consistent behavior. The extensible SDK class
(oeqa.sdkext.testsdk.TestSDKEXT) also has a common "run()" function, but
no hooks have yet been added as there is not currently a known use case
for create derived classes.

These changes should be purely organizational; no functional changes
have been made to either the standard SDK or extensible SDK tests.

[YOCTO #13020]

(From OE-Core rev: a06d53928b22d5f88276023c4d57b206db2f27f9)

Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>

OETestDepends doesn't work with parallelism and in this case we don't
really need this dependency, it would just short out some tests quickly
in the rare case the esdk environment was broken.

Currently this is masking tests which is a much worse problem and we
can't make OETestDepends work reliably with parallelism so drop the
dependencies.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

With the new OEQA thread support there are problems running
devtool twice at the same time because only one instance of
bitbake/devtool is allowed.

[YOCTO #11450]

Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

test_extend_autotools_recipe_creation needs libxml2 so ensure this is
installed/present as it may not be in the minimal eSDK case.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Skipping the tests if a toolchain wasn't installed out of the box (for example,
a minimal eSDK) doesn't make sense as the first thing the tests should do is
install a toolchain.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Use the finally: block to always to cleanup.

Now that the test harness in testsdk.bbclass has monkey-patched
CalledProcessException to display the output we don't need to do that in the
test case.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

These methods are class not instance methods, so the argument should be cls not
self.

Also don't put variables into cls that we don't need there.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

This is admitted a bit of a hack but it does allow a number of significant sdk
tests to run successfully and hence improves testing of eSDK which is good.

I'm therefore proposing we do this until we come up with a better solution
since the current lack of testing is worrying and would have caught other issues
had it been present.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

This removes the need for some of the ugly decode calls with hardcoded
locales.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The directory list of sdk tests to run can vary so this code effectively selects
a random set of SDK tests to run in the eSDK. We want to attemp all the SDK tests
so remove the element selection.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>