Currently, the only way to pass parameters to Avocado is by using the
variants layer, that is, one of the existing varianter plugin
implementations.  This was based on earlier design decisions, that
we're trying to fix without breaking expectation and compatibility.

While it'd makes sense to support parameters created by the varianter
layer itself, together with non-varianter parameters, it seems that we
can start by adding support for one or the other being used at a time.

This commit does exactly that: add support for a method of passing
parameters via the command line for all tests in a job, without
having to resort to the varianter.  When the varianter is used,
it takes precedence and the core test parameter passing support
is ignored.

This should solve a number of use cases that require one-time
executions of tests with different parameters, especially
executions during test development and debugging.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Depending on the number of parameters, generating the Variants can be
compute intensive. This patch adds the ability to dump/load the variants
to/from a JSON file so the Variants generation can be offloaded from the
machine under test.

Reference: https://trello.com/c/llZJKBdiSigned-off-by: NAmador Pahim <apahim@redhat.com>

A lot of the core Avocado code still refers to "mux" based terminology.
For instance, what was previously "mux_path" is now "parameter paths",
and what was previously "mux" is now really variants.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The default parameters mechanism proved to be confusing, overlapping
and thus was scheduled to be removed.  This implements the removal
of the default_params API.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The current TestName class records more than a test name (according
to the Avocado specification).  It records, and by default, presents
the Test ID (__str__() and __repr__()).

The Test Name, again according to the Avocado specifications, is
contained within a Test ID, so it's not necessary to have two
different classes IMO.

Finally, the str_filesystem() method was adapted to be coherent with
the fact that it returns a file system representation of the Test ID,
not the Test Name.  It also became a property, to match the same use
of str_uid and str_variant.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The suite order means the order in which the variants will be applied to
tests. Right now we run all variants of first test, then the same for
the second, third, ... tests. The new option "--execution-order" allows
to alternatively specify "tests-per-variant" mode where we run first
variant of all tests, then second variant, third, ...
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Currently the yaml_to_mux plugin is a core plugin without properly
defined requirements. Let's separate it to optional_plugins, define
dependencies and also build it separately in RPM.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The "avocado multiplex" command is misleading as multiplexation is only
the generic concept used by one of our varianter plugins
implementations. Let's change the command name to "avocado variants"
which better reflects what is it used for.

As people depend on "avocado multiplex" command let's keep both of them
for now to give people time till Avocado 52.0 to migrate.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Some spelling issues, broken link fixes and updates related to recent
changes in Avocado.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

This adds the support to define per-node filters, which take part of
environment and are evaluated during multiplexation.

The basic idea is to define relations ({could be only used | could
not be used} with other branch), which makes it a bit different from
what we know from `--mux-filter-{only|out}`:

1. They are applied per complete variant (because the filters are
   compound of per-leaf-filters)
2. They don't remove/keep the nodes, but they only evaluate whether
   this resulting variant makes sense (whether it passes the filters)

See the updated documentation for details.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

All the plugin interfaces defined in `avocado.core.plugin_interfaces`
ommit the "plugin" term, simply because this is already qualified in
the module name.

Let's also standardize the Varianter interface to "plugin-less" name.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Finally after all the refactoring, refining and modifying here is the
up-to-date documentation which follows the current structure and tries
to describe both theoretically and practically how are test's parameters
produced and how they can be used.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>