[TEST] adapted to API

WFQ and Dummy algorithms had different APIs. WFQ is the algorithm used
in life mode and Dummy only exists to make testing easier. Therefore,
Dummy should adapt to the API of WFQ. This patch changes the test to
match this new API.
Simplify implementation.

We do not need the attribute "queues". Therefore, we do no longer require
it. Also we change the last use of $self->queues to use the given queue
list.
[DOC] clarification

The doc said the package implements a test for WFQ. No, it is not a
test. It is real.
[RFK] adapt API to WFQ API

Both WFQ and DummyAlgorithm implement function they inherit as stubs
from Algorithm. Dummy is needed as replacement for WFQ in testing
only. Therefore, it should have the same API. This in turn means that
Algorithm also has to match the API of these two.

As a result all algorithms now work on a list of queues received for
get_next_queue. An attribute "queues" and function to manipulate this
attribute are no longer needed.
[TEST] make sure db exists when needed

I reordered the statements for creating the test database from
fixtures. Before the db was not yet ready when it was needed to create
the first objects.
[TEST] make sure db exists when needed

I reordered the statements for creating the test database from
fixtures. Before the db was not yet ready when it was needed to create
the first objects. I realized this means the "construct_fixture has to
be in a BEGIN block since the DB is needed for "use Controller" which
implies a BEGIN itself.
[TEST] make sure db exists when needed, with BEGIN

I reordered the statements for creating the test database from
fixtures. Before the db was not yet ready when it was needed to create
the first objects. I realized this means the "construct_fixture has to
be in a BEGIN block since the DB is needed for "use Controller" which
implies a BEGIN itself.
[TEST] Dummy algorithm with and without removing choosen element

Usually the scheduler will remove the queue choosen by DummyAlgorithm
from the list of queues to work on. This test should check whether
DummyAlgorithm work with and without this removal.
[TEST] WFQ with providing queue list

The WFQ algorithm expects a queue list. The test now does this.
[TEST] reorder fixture to fullfil constraints

When using mysql for unit testing constraints need to be fullfilled. I
reordered the tables to make sure e.g. a host exists before it is
refered to.
Also, since mysql wants to fill "autoincrement" values itself we can no
longer set ids in the fixture.
[TEST] make sure db exists when it is needed

Some parts of the db are now already needed when the scheduler modules
are used. Thus, we need to make sure they are available then. I
reordered the creation of the db from fixtures to ensure these parts are
available.
[TEST] make sure db exists when it is needed

Some parts of the db are now already needed when the scheduler modules
are used. Thus, we need to make sure they are available then. I
reordered the creation of the db from fixtures to ensure these parts are
available.
[FIX] update in update when needed

When algorithm->update_queue is called in tests it gets a
MCP::Scheduler::Queue object. The scheduler however provides a DBIC
object. The DBIC object needs an explicit update call which is included
now. We simply check whether the object offers an update function and
call it if so.
[FEAT] Scheduler with non-DBIC objects

The scheduler was way to slow because every check was done on
DBIx::Class database objects and thus resulted in a database query. To
reduce the number of queries I converted the scheduler to use Moose
objects. These are created from DBIC once for each get_next_job call.
[FIX] deprecated "use UNIVERSAL"

you no longer need to use UNIVERSAL to access its methods. Since it
generates a deprecation warning, I removed it.
[FIX] Write values to db

For values to be written to DB a call to $db_obj->update is needed.
[FIX] create a new PrioQueue on every call

The PrioQueue has a list of associated testruns. This list is created at
PrioQueue->new. If we keep the resulting object, testruns will never be
PrioQueue->removed from PrioQueue. Thus, I now create a new PrioQueue
PrioQueue->object on every get_next_job call and all is fine.
Merge branch 'master' of wotan:/srv/gitroot/tapper/Tapper-MCP
[TEST] make sure DB exists when needed

The Scheduler needs a database when the module is used. Thus we need the
"use Tapper::Schema::TestTools;" before the first use of a Scheduler
object. This patch makes sure the db is available by reordering or
adding the above mentioned use.
Don't put model into namespace

In Scheduler::Job host features are injected as functions into the name
space. This has the disadvantage that these functions may clash with
existing ones. This applied to Tapper::Model::model. Therefore, we can
not inject Tapper::Model::model as model into the Scheduler::Job
namespace.